Dear Lars,
in message AB4979EC12A5EB419810807434495A17283C1E@svex01001.wago.local you wrote:
Which is an unsupported mode of operation which works for a handfull of experts and causes confusion with many, many newbees.
How do these lines of code confuse a newbie more than any other code in the file?
It's not the lines of code, but the mode of operation. People tend to underestimate the complexity of the task and the impact of the required modifications.
As I always do. Attach the BDI, burn to flash, start in GDB.
There are 53982 other hardware debuggers out there and only the minority (is there actually one besides the BDI?) support the burn to flash feature you rely on. So if you need to start U-Boot
C'me on. You must be joking. Please name a few commercial debuggers which do not support flash programming. Maybe we should add a list of such broken devices to our wiki so people can avoid them?
Let me check:
* Abatron BDI2000: ok (of course) * Windriver visionICE II: ok * Lauterbach Trace32: ok * Macraigor Wiggler / Raven / usbDemon: ok * Agilent 3070 Series etc: ok
Even the free BDM4GDB project suports flash programming.
Please be specific: which BDM/JTAG debugger cannot program flash? I really would like to know to be able to warn our customers.
You can do this if you know exactly what you're doing,
Isn't this what is assumed here anyway?
Yes. People should think, machines should work ;-)
There are areas, where small errors have small consequences which are easy to spot. AQnd there are really nasty problems. If you look back at the archives you will see that this is one of these nasty problem domains. And it's a FAQ.
Best regards,
Wolfgang Denk