Skip to main content
Topic: STK500 Merge (Read 4502 times) previous topic - next topic

STK500 Merge

Hey guys;

Im doing my part and triyng to merge the STK500 programmer into the v4 firmware. I got the mode all setup but i have some issues I was hoping the community could help with.

First here is the source for the STK500:
http://code.google.com/p/the-bus-pirate ... 2FSTK500v2

First my original thought was; as soon as you select stk500 mode; it asks 'are you sure' if so it jumps into STK500 mode which you then need to d/c from terminal and use it with whatever AVR programmer you want. but then I thought; the user should be able to enable the power supplies if he wants. So now im thinking via macro. So first question; which is better? Mode with agree? or Macro?

Second; I understand the UART stuff I think; but whats the best way to move the SPI related junk into it?

third; _CONFIG1(xx xx xx) do we need those anymore? i assume there config bit editors; should I just delete them?

Re: STK500 Merge

Reply #1
Just an update. I got it all in there and no build issues; all fixed. I cannot test until I get home. but I went with Macro method. any objections?

Re: STK500 Merge

Reply #2
So exciting! I finally got home and tested the STK500 mode I added. It doesnt quite work (would have been amazing if it did, but i didnt expect it too) but it was working alot better then expected. AVRdude was able to communicate with it and you could see the status light flicker like crazy :D But its acting like the AVR i hooked it too is not responding; so I checked connections and everything looks good (I did get this AVR out of my 'unsure and/or programmed avrs' collection so it could very well be a dead or ISP disabled AVR. I will test more!

Hopfully I will get this working!.

So far this is how you operate it.

Quote
>m
1.UART
2.SPI
....
9.DIO
10.STK500
>10
STK500 Clone Mode; Setup your peripherils if needed and hit Macro 1 when ready...
STK500>W << Power supplys on
Power Supplies ON.
STK500>P
Pull-up resistors ON.
STK500(1)
Entering STK500 Programming Mode; Once you enter this mode you must reset the device to get out.
*Warning Disconenct from terminal before attempting to program!*
Enter STK500 Mode?
Are you sure? y
###
<disconnect and program>

This is sweet.
[/quote]

Re: STK500 Merge

Reply #3
Oh also; here is the reply I am getting from AVRdude and the command im running. Any suggestions to look at and/or ideas please share them! No matter how unsure you are; all ideas are welcome!

Quote

avrdude -p attiny25 -c STK500v2              -P COM4              -B 5  -b 115200 -F -U flash:w:main.hex

avrdude: stk500v2_command(): command failed
avrdude: stk500v2_command(): unknown status 0xc9
avrdude: stk500v2_program_enable(): cannot get connection status
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATtiny25 is 1E 91 08
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
        To disable this feature, specify the -D option.

avrdude: nope. Keep trying Brent! :D <3 U

Re: STK500 Merge

Reply #4
Well I figured it out; the communication between the IDE/programmer is great. The issue is SPI doesnt seem to be working; I hooked her up to the OLS and saw a CLK signal (1) but every other line (including RESET which should be low before any SPI communication) just remain high...

So I guess the next step is to learn SPI :D I was hoping I could get away with including spi.h and just utilizing that; but it doesnt look like it. Unless any BP developers have any ideas why that wouldnt work, let me know!

unless; should I be using pull downs on this? And/or should I be enabling or disabling the pull-ups (hooked to 3.3) I want to keep VREG so I can power the attiny im trying to program..

let me know :D thanks.

(I should goto bed but I keep telling myself, "1 more build; just one more try" :))

Re: STK500 Merge

Reply #5
My plan was to use the EEPROM to save the STK500 mode so it starts up there every time (until normal is pressed). I think the problem with SPI is that the Bus Pirate already has it configured a certain way, and then the STK500 port doesn't reconfigure them properly unless the PIC has just been reset.

I think after saving the mode (maybe we need a new config menu for setting the different modes in the EEPROM?), it should probably say 'Mode saved, disconnect your terminal and reset the Bus Pirate to startup in XXXXX mode". Just my thought though.
Got a question? Please ask in the forum for the fastest answers.

Re: STK500 Merge

Reply #6
That would be sweet... actually..
thats a much better idea....... So that means the load eeprom command should be like the very freakin first thing you do upon entry...

Its just the eeprom allocation is already scaring me; we will need a eeprom allocation header file filled with defines; definging every single byte we need! Although I did have an idea about using a struct

Re: STK500 Merge

Reply #7
Calling all BP developers and PIC programmers :D I dropped the STK500 mode due to Ians idea that it should be a startup mode depending on the EEPROM.... That seems like an OK idea (although both might be sweet, perhaps a Macro to make it 'On reset start in STK500 mode (Hold normal on reset to go back to normal)' might be better, but thats for another day)

Anyways; I have a vested interested on getting the STK500 emulator to work on v4. I have a question;;

What are these:

//set custom configuration for PIC 24F
_CONFIG2(FNOSC_FRCPLL & OSCIOFNC_ON &POSCMOD_NONE & I2C1SEL_PRI)      // Internal FRC OSC = 8MHz
_CONFIG1(JTAGEN_OFF & GCP_OFF & GWRP_OFF & COE_OFF & FWDTEN_OFF & ICS_PGx1) //turn off junk we don't need


im guessing this is simulure to AVRs fusebits kind of (loosly) but software controlled. Like you can say I dont need this or that so disable to save power. or whatever.

My main question is; how can you make a PIC start up and ignore that _config and lets say I want to press a button that runs that _config command?

Is that possible?

What I need to do is in the BP v4's main() I need to do somthing like this sudo code:

ReadSetting = ReadSetting from eeprom(Address,default)
Code: [Select]
int main(void)
{
Var = ReadSetting(BP_START_MODE,0x00);
 switch var
  {
    case 0x00:
          break;
    case 0x01:
          Run(Those config settings);
          Do not continue in normal BP mode;
          Startup(STK500_MODE);
          break;
    default:
          break;
  }         
Startup(NORMAL_MODE);
//we wont get here
}

not literally like that; but for example. How could I do that?

Re: STK500 Merge

Reply #8
[quote author="BrentBXR"]
What are these:

//set custom configuration for PIC 24F
_CONFIG2(FNOSC_FRCPLL & OSCIOFNC_ON &POSCMOD_NONE & I2C1SEL_PRI)      // Internal FRC OSC = 8MHz
_CONFIG1(JTAGEN_OFF & GCP_OFF & GWRP_OFF & COE_OFF & FWDTEN_OFF & ICS_PGx1) //turn off junk we don't need


im guessing this is simulure to AVRs fusebits kind of (loosly) but software controlled. Like you can say I dont need this or that so disable to save power. or whatever.[/quote]
They are the config bits, similar to fuse settings used in an AVR uC. You don't have to set them in code, you can also use MPLAB IDE for setting them (from one of the menu options) but this method is preferred as you can just share the .c files and people usually do not care about project files (sometimes compiler and linker script folders are off), they might create their own and skip the ones shared.

[quote author="BrentBXR"]
My main question is; how can you make a PIC start up and ignore that _config and lets say I want to press a button that runs that _config command?

Is that possible?

What I need to do is in the BP v4's main() I need to do somthing like this sudo code:

ReadSetting = ReadSetting from eeprom(Address,default)
Code: [Select]
int main(void)
{
Var = ReadSetting(BP_START_MODE,0x00);
 switch var
  {
    case 0x00:
          break;
    case 0x01:
          Run(Those config settings);
          Do not continue in normal BP mode;
          Startup(STK500_MODE);
          break;
    default:
          break;
  }         
Startup(NORMAL_MODE);
//we wont get here
}

not literally like that; but for example. How could I do that?[/quote]
That method you used is not possible as I know as config bits are compiled and set in the hex file at the respective page. But you can write to them in your code ie. bootloader code can write on itself and config bits (which brakes the bootloader and even the code you are uploading, so they either complain or do not allow this operation) and you reset the uC for it to work with the new settings. You can possibly do sth like this (means: check bootloader code), but you have to think about a way to store and load the old settings back when they are required.

Re: STK500 Merge

Reply #9
The STK500 mode should be able to run with teh config bits set in the v4 by the bootloader. It is not possible to change the config bits, the bootloader will protect them and not overwrite them.
Got a question? Please ask in the forum for the fastest answers.

Re: STK500 Merge

Reply #10
thats what I figured. Like setting fusebits via software; it only works one time.