hi,
i have damaged the boootloader/bsp from my connectcore9c. now i try to program the device over the raven-debugger but it fails.
i have the devkit with gnu. is there a serial programmer on it? i don´t know.
has somebody this problem before and how did you solve this?
thank you
tom
When your NET+ARM device (CC9C, ME, etc.) powers up it will immediately begin executing whatever code is stored on CS0 address 0x00000000; this being the device’s flash.
It does not matter if the data at this location is valid or not, the processor will attempt to execute it. In teh case of the data being valid, there should be not problem, unless your applciation image is corrupted (but this is an isue for another forum discussion).
If, however, the data at this address is corrupted it is likely that the processor will start up in an invalid state, cause the problem you see with the debugger (processor already running, etc.).
This is what you should try:
- On the CC9C module is a four-pin connector, labeled P1. Locate this connector and short together pins 1 and 4.
- Power up the CC9C module. The shorting together of the two aforementioned pins will effectively disable the flash, thus preventing the processor from running any code stored within.
- Connect to the unit with the debugger and load you application (best to use naftpapp), HOWEVER, do not allow the program to execute, e.g. do not tell it to continue.
- Remove the short on P1.
- Allow the application to continue.
- With the applciation up an running use your favorite FTP client and upload a new boot loader (rom.bin) image.
- Assuming the stored application image is valid the unit should run it, once you exit the FTP client and the unit resets itself.
This same procedure can be applied to any of the Connect devices. The location of the 4-pin connector varies on each platform, but you will always have to short together pins 1 and 4. Here is the pertanent information:
- Connect ME/Wi-ME - The appropriate connector is on the development board, itself, labeled MFG (or P5)
- Connect EM/Wi-EM - The connector is lcoated on the module, labeled P4.
- Connect SP - The unit will have to opened up (should not be a problem seeing as the unit has to be opened in order to debug, anyway). The connector is labeled P1.
Cameron
i solved the problem!
there is no serial programmer, you can only restore the bootloader via the debugger.
the upload of the bootloader is described in “NET+Works with GNU Tools Programmers Guide” chapter “Troubleshooting” ->“Restoring the contents of flash ROM”.
if you have problems to start the raven debugger as described in the “net+works with gnu tools - getting started guide” then use arm-elf-gdbtk instead of gdbtk! that is a fault in the docu!
t.
It seems like I have a similar problem, though using “arm-elf-gdbtk” instead of simply “gdbtk” doesn’t help.
Perhaps I should give a more detailed description of the problem…
The application I’ve loaded into the system works perfectly well when I run it through the debugger (a Majic), but there seems to be something wrong with it when I try to run it without the debugger (i.e. from flash). The problem is that the application stops responding (sometimes after 10 seconds, sometimes after 15 minutes). I think this might be due to an error when using semaphores (which might lead to deadlocks), so I’ve changed the software to see if it works. The main problem (and the reason I now write this message) is that I can’t get the image down to the flash! Every time I try to run the naftpapp example using the debugger my MDI server give me the same response: “Target processor not responding (may be in sleep mode)” followed by “Target processor available”. Sometimes this makes the ftp command fail (with an “unknown errorcode”) and sometimes I come to the login prompt (name: x.y.z.q:(none)) where I’ve tried answering most things (and of course I’ve tried the (none) name numerous times). No matter what name I’ve tried entering I can’t login (though I do get a request for a password if I leave the name line blank), and hence I can’t uppdate the flash application nor update the bootloader.
If anyone knows what I could try, I’m keen on trying. If there is some other way to get the application to flash or reset the bootloader, it would be a step forward - as I would be able to test my new solution and I would know what to do if it fails again. Any kind of feedback is welcome.
You should be able to recover the bootloader via the JTAG; I already succeeded once, when I put a wrong bootloader into my Digi dev board. Put the standard bootloader through the JTAG to be sure it will work. Otherwise, put a custom bootloader that allow you to recover the firmware and/or the bootloader into flash.
Paul
Thanks for the fast reply. By now everything works!
Hmmm… There seems to be a new problem… I can’t run the program in the debugger…
In more detail:
When I shortcut the pins to run the naftpapp example and reprogram the flash everything works.
When I run the applicaion from flash it works, except that I still get some errors I didn’t get when running the same application using the debugger.
When I try to run the application through the debugger, I always get an error message saying that the MDI server can’t write data to some part of the memory, and if I run the debugger after this I get “timout trying to access register 15”. If I shortcut the same pins as I do when I reflash the card, the debugger starts - but no application runs (perhaps not very surprising, since no application has been loaded into card memory).
I still don’t know if the trouble is due to the i2c fails I keep getting when running the flashed version of the application.
The problem has been solved - partly… We still need to shortcut the pins and reflash the bootloader to get a new application down (and if we have our application on the machine we can’t run the debugger), but as long as we don’t put our application on the board there’s no problem running the debugger.
We still have a wierd problem when using any gcc optimization (with optimization the application is malfunctioning when running the flashed version), as the application works perfectly in the debugger but crashes when we run the same application (of course recompiled using a “non-debug” bsp) from flash. We’ve checked numerous times to ensure that we have the same optimization in both cases, and the only time it works in both cases is when we turn all optimization off. If anyone has a clue as to which gcc-flag we need to include to get the optimized application to work when running from flash, please let me know.