I am doing something wrong, but if anyone could point out my issue I would appreciate it. I am trying to load a new image, trying to get the sd version up and working, but the bootloader keeps tell me nothing to do. The write program option is grayed out. What step am I missing? I select the device, dsPIC33FJ and the sub device field 128GP204, and the comm port which is fdti. I load the nex file I made. I get a complaint in the ds30loader that that Unknown data found 16 bytes at 0xf80010
then in blue The hex file contains code that will overwrite the bootloader.
Hexfile successfully pared
44032 program words found in 688 rows
0 Eeprom words found
8 config words found.
Hi Rhyde - can you upload the .hex file? I'll test it out on my board.
Thanks!
Ian
[quote author="rhyde"]
I am doing something wrong, but if anyone could point out my issue I would appreciate it. I am trying to load a new image, trying to get the sd version up and working, but the bootloader keeps tell me nothing to do. The write program option is grayed out.[/quote]
Yep, that's the message you get if the write option is not selected.
What step am I missing? I select the device, dsPIC33FJ and the sub device field 128GP204, and the comm port which is fdti. I load the nex file I made. I get a complaint in the ds30loader that that Unknown data found 16 bytes at 0xf80010 then in blue The hex file contains code that will overwrite the bootloader.
Hexfile successfully pared
44032 program words found in 688 rows
0 Eeprom words found
8 config words found.
The total program memory available is 44032 program words and your hex file appears to fill the entire program memory which would also overwrite the boot loader, so I guess the ds30loader stops this from happening and won't write the hex file. I'm not sure why your hex file is so big... I seem to recall the original SD hex file was closer to 78% of program memory (unoptimised).
hm am I out of space or not? I just tried to build a test image, and I must had done something wrong. Let me poke around at it.
You are using the ds30loader?
When you try to write to a protected area (e.g. fusebits or bootloader area (this is the same I assume for pic30, for pic24 it is)) the program flag is cleared in the ds30loader and grayed out. The problem is the filename is remembered whether it is recompiled or not.
The solution is to only export the flashmemory (minus the bootloaderspace) without the fuses and to delete the configfiles in the the ds30loader directory and get the settings.xml file from the svn.
This is some kind of protection mechanism.
Ah, how does one export with such exclusions?
I don't have experience with the webplatform, but for the buspirate you don't include the configbits and export only 0x0000-0xa7ff. I mostly use the generated hex by MPLAB (somewhere in mplab you could disable the set config bits). However this produces lowercase .hex files which breaks the commandline util.
The bootloader lives in the last flash block (so don;t export that one!) I believe the unpatched bootloader lives in the last _two_ blocks. with the development of the bootloader for the buspirate we tweaked that to just 1 flashblock. Dunno what it is for the webplatform.
Using mplab, but no clue where these options are. Fixxing lowercase files is not hard if I know that is the problem.
There is a thread in de BP development that describes the 'trouble' when compiling for the ds30 loader. Please be aware that the buspirate has a different architecture and memory layout.
http://dangerousprototypes.com/forum/in ... opic=253.0 (http://dangerousprototypes.com/forum/index.php?topic=253.0)