Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bootloader won't write start address [solved]
#1
I’m using a PIC18F46K80 with your bootloader (V3.0.0 firmware and V1.4.6) on a HEX32 file generated using the Microchip C18 compiler and it all seems to write the code correctly, but I cannot get it to reset the start address to the user code so my application doesn’t start! I’ve used a previous version with the Hitech PICC18 compiler and it works beautifully – what am I doing wrong?
Reply
#2
Have you enabled any option under the advanced tab in the gui?
Post the hex file and a hex file where you have read the PIC after writing it with ds30 Loader.
Reply
#3
(2012-04-10, 12:04:12)Mikael Gustafsson Wrote: Have you enabled any option under the advanced tab in the gui?
Post the hex file and a hex file where you have read the PIC after writing it with ds30 Loader.

Thanks for the quick response. The only option I enabled is "don't write empty pages" but I've tried it with and without this. In the firmware I first tried it with both bootloader and goto protection enabled, then without goto protection. Attached files are for the latter.

Am I right in thinking that the GUI rearranges the hex file? The data sent doesn't look consistent with the file as loaded.


Attached Files
.zip   LubriGuard Display Box.zip (Size: 25.44 KB / Downloads: 7)
.zip   Bootloaded code.zip (Size: 12.69 KB / Downloads: 12)
Reply
#4
The file Bootloaded code.hex contains only the boot loader, I need a readout after you have made a write from ds30 Loader GUI/console.

Yes the gui moves the goto at 0x00 to just before the boot loader.
Reply
#5
Apologies, I exported the program memory from MPLAB without first reading back all the bootloaded code into MPLAB. Here's another try.

I've been trying to work out how and when the bootloader writes the start address. The protected goto code appears to overwrite the bootloader start address whenever the GUI/hex file tries to write to block zero, which makes sense in case of an incomplete download, but does the GUI add a line at the end to rewrite the goto address to the user code's address? If so, this seems to be what's missing. Whatever I do, with or without the goto protection, the first 4 bytes read "goto <bootloader address>" from very early in the bootloading process (if I interrupt it) to the very end. I even manually added a line at the very end of the hex file to write the correct address but either this didn't get written or was subsequently overwritten by the GUI.


Attached Files
.zip   Bootloaded code2.zip (Size: 33.84 KB / Downloads: 11)
Reply
#6
Thanks. The goto to the boot loader at 0x00 must remain there, otherwise the boot loader wouldn't start each time and I guess it wouldn't be a boot loader anymore. The file you uploaded looks good. There is a goto to the application at 0xfdfc, right before the boot loader where it should be. It points to 0x7048 which is your application entry address. Also see page 24 in the main manual.

Have you setup the configuration bits correctly in the boot loader, they should be the same as the ones you use in your application.
Reply
#7
Mikael, thanks for the feedback and the excellent support throughout. I now understand how the bootloader vectors to the user code - the bit I didn't realise was that the bootloader start code is called every time the PIC restarts and then vectors onto the user code after the Receive function times out. I believe on the previous version the zero addressed goto was changed to start the user code directly with the bootloader just sitting at the top out of the way. You were right by the way, the config settings were the problem.

Anyway, the whole process works now with a user code erase of the FDFC goto to re-invoke the bootloader. I assume this is the recommended method.

Thanks again!
Reply
#8
Great!

I am not sure I follow you on the last line. All you need to do to invoke the boot loader is to make a reset. By software, master clear, or power cycling. Then you need to perform the write operation before the boot loader times out and load the user application.

Personally I prefer to implement a reset command in the application which resets the pic by software. Then I use the reset command functionality in ds30 Loader GUI. That way you don't need to do anything manually.
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)