Hi, I'm using LPC2368 as my cpu. While I debug my target - I have the ability to watch Disassembly lines in mixed mode (C code & Assembly), this help me to find the location of every command in my C code. Because I create "Data Abort" trap error - I can test the exact adress that I get in this "Data Abort" and find the exact line that it happens. When I send the code to my customer - If he gets "Data Abort" - the Error Adress is displayed and he can report it to me.. But - I already have a new revision and the adresses is not the same as the revison that my customer have. I can save all the files (I have many) and when I get this error - I should restore to this version - but it looks very messy. The best way is to tell the LINKER to create a .lst file with the final code (C & ASM & adresses) - so I can search in one big file the adress.
I Try many switches in the Linker section, None of them create this list file. Also the --list=file do nothing ,even when I use it with other switch (like --info=debug...)
Any help? Doron
I think the above can work if you use THROW inside the abort handler. I never actually tried this myself, but it should work if the jump variable have global linkage.
Hi Tamir, It seems that you don't understand the exact problem. When there is "Data Abort" the CPU jump to the DataAbort adress with the R14 holding the adress of the line that create the error. I create a function that show on the unit screen this adress. My custumer - write this adress and report it to me.
The solution that you suggest force me to install a lot of remarks in my code. My code is huge. I can't mark every line there just for the code report.
I solve this problem (The hard way) that I turn on the list option for every C file, I also create the map file with all the list option.
Now when I have the Data Abort Error - I search in the map file in which function the error happens. then I go to the LST file with that function - make the calculation ofset and find the C code line.
But I wan't the easy way - If I have one list file that have it all - I can backup only this file , instead all the project...(And no need to restore it)
Thanks, Doron
Why are you making your life so hard? If you can revert to the exact sources that induced the problem, all you need to do is start the simulator or a real target to see the offending instruction. Why browse .lst files and all that...
Source control versioning would dictate that you have stored - or can recreate - whatever source you used for any released version of the program. Subvers, CVS etc will not store full copies of files - they will just store the differenses between different versions.
I also make sure to save the map file for every build together with the produced binary.
Hi Tamir, It force me to save evry time that I send new revision - all the C,LST,ASM,MAP.. files - instead of ONE file (list file)..!! Also to view ONE list file is much easier than - restore the old revision and run it on a target..
Yes - it forces you to have good working order. It isn't really like you get any huge amounts of information to keep track of. How many releases do you send out every day?
When I send the code to my customer - If he gets "Data Abort" - the Error Adress is displayed and he can report it to me.. But - I already have a new revision and the adresses is not the same as the revison that my customer have. tried thatb once, and it did not take long to find out how messy it was and change it to void error (char error_number)
Erik
Thanks for all the help. I still think that if the linker has a LIST option - that works - it could save me a lot of time...
It force me to save evry time that I send new revision - all the C,LST,ASM,MAP.. files - instead of ONE file (list file)..!!
No, it's not this issue that forces you to do that. For two reasons:
1) You do not actually have to save all those files. You only have to save the actual source code and build configuration files. You can create all the others if and when you actually do need them.
2) Don't kid yourself: you're already forced to save those files regardless of this issue, because that's the absolute bare minimum of configuration management. You have to be able to exactly re-create from source every binary you ever delivered, make modifications to that, and thus provide incremental updates.
How else do you think you'll ever manage to analyse suspected bugs in old versions? How will you fix them?
Finding the exact code location of a (rather special type of) bug in an older version is at most a very crude first step of software problem analysis. If you can't recreate the exact, fully debuggable binary image and rebuild it after making a tentative fix, there's just no way you can fix any bug. Most importantly you'll never know if that modification actually fixed the bug or not.