I have problems with the bootloader (NetOs6, GNU, My HW is the NET+50 BGA-Board) I manage to debug my application with GDB. All works fine. Then I run naftpapp. With a FTP-Shell I do the following: ftp> open 150.100.49.251 Verbindung mit 150.100.49.251 wurde hergestellt. 220 NET+ARM FTP Server 1.0 ready. Benutzer (150.100.49.251:(none)): root 331 User root OK, send password. Kennwort: 230 Password OK. ftp> bin 200 Type set to I. ftp> put c:\image.bin 200 PORT command Ok. 150 About to open data connection. 226 Transfer complete FTP: 432012 Bytes gesendet in 22.95Sekunden 18.82KB/s ftp> close 150.100.49.251 221 Goodbye. ftp> In the serial-Port-Shell: FTP: Flash download complete. Resetting system in 10 seconds. After 10s nothing happens. - My system seems to be dead. I thought the system should boot… I don’t know if there is an opportunity to debug the startup-code from flash. What should I do? Did I understand anything wrong? Regards, Chris
Hello Chris, is this the same problem (see: “run app from RAM” in the Sample Application Thread)? Try to make an uncompressed image. Are you using a Raven as Debugger? I am using the OCDCommander from Macraigor (www.ocdemon.com) for simple debugging. With this tool, you can easily halt the target and look at some memory (for example in the flash (did programming work?) or the addresses you’ve linked your application (did decompress / memcopy work)). The debugging should also be possible with the GDB, but I can’t tell you how, because I am using GHS tools. Regards, Volker
The procedure should be as follows: I suggest since they got things out of scope, first make the Bootloader image by doing a make on the bsp which automatically outputs the bootloader image: In the netos\src\bsp directory make PLATFORM=net50_d Following this do a make of your application image as well so that it is ready for the firmware update. After all these run the naftpapp and then burn rom.bin of bootloader at
etos\src\bsp\bootloader\romImage. After this run naftpapp again and then this time burn the image.bin of your application. The board will reset in 10 seconds and you will see the new image will come up fine as it will out put itself in the Hyper Terminal. This should clarify the issue. The bootloader gets written to 64K portion of the flash which is the lower memory and then image.bin gets written to the after following this portion. You can use reaming flash size for other purposes as long as you specify the memory locations correctly meaning you don’t overwrite other sections.
YES!!! It works! I didn’t read anything about programming the bootloader until now and I didn’t found the path of the rom.bin of the bootloader before… I thought it is included in the image.bin. But now my system starts up automatically. - I am very lucky! Thanks a lot!!! Chris