Running New Firmware With An Existing AS7 Project
So the whole point to debugging is to fix things, right? And we would never make a change without testing it for bugs, right?
To continue using the PulseIn issue I've been working, let's assume I've made some code changes and built new firmware to test. Since our firmware builds in the same location everytime for CircuitPython, and our project file is already mapped for that location, why create a new project? Especially when Atmel Studio will recognize that the firmware files have been updated, and give us the option to use the update. However, it isn't a perfect, seamless experience. So here are a few tips:
-
Close AS7: I have gotten into the habit of closing Atmel Studio when ever I'm building new firmware with changes. The not-as-smooth-as-it-could-be process goes a little smoother. So, I suggest closing AS7 (or at least the project), building the new firmware, then re-opening AS7 and/or project. Using the available "Recent" open commands cuts down on a couple clicks.
-
Wait: AS7 is a LARGE program (Visual Studio framework, after all). It takes a while for it to scan and load all of the project files (YMMV if your PC has worse/better specs than mine). Don't immediately click "Start Debugging…". You can have the Solution Explorer window open to watch the status: it will change from "Loading" to "1 project" when it is complete.
- Reload: Once AS7 finishes loading the updated firmware files, you will be greeted by the following message. Click "Reload".
- Remap: The following window will eventually pop up. Click "Finish" to confirm that all the files have been reloaded. (Note: the "Missing" message is mis-leading; scroll through the actual list to find any errors)
- Choose The Right Option: Once AS7 finishes remapping the updated firmware files, you will be greeted by one of those scary message boxes with too much text and too many buttons. It seems counterintuitive at first, but the option you'll want to select to use the updated firmware is "Discard". After reading the descriptions in the message box a few times, it makes sense. Here it is in all its glory:
-
Reset The Programming Settings: Remember that "very, very important setting" discussed earlier? Well, AS7 likes to forget all about the fact that you changed it. So, before you send any programming commands to the J-Link, make sure you go back to the Project Properties window and change "Erase entire chip" back to "Erase only program area". Then, save. If you miss or forget about this step, fear not; it is recoverable.
UPDATE: Due to bug fixes in an AS7 update, released 6/22/18, the issue above seems to be corrected. However, keep an eye on it.
-
Verify Breakpoint Addresses: It is most likely that at least some of the functions you have breakpoints set for, are at new address locations. The quickest way I've found to verify them, is to "Start and Break…" the board into a paused state, right-click each breakpoint in the Breakponts window, and select "Goto Disassembly…". That will highlight the breakpoint address in the Disassembly window. The function addresses are usually blocked together by function, with spaces or filepaths separating any jumps. If the highlighted address appears to be in a different location than it should, just search for the function in the Disassembly or GDB window as described earlier. Then change the breakpoint's address. Another tell-tale sign is if any output actions are giving totally different results (changed to
could not evaluate
oroptimized out
) than before.- Breakpoints set with New->Function Breakpoint: Any of these breakpoints that have moved memory addresses with updated firmware, will have the breakpoint address set to
0x0000
. Simplest way to fix it: change the breakpoint function name (e.g. drop the last character), save, then change it back. Automatic address update. You will need to have the board paused for this.
- Breakpoints set with New->Function Breakpoint: Any of these breakpoints that have moved memory addresses with updated firmware, will have the breakpoint address set to
Now it is once again safe to start debugging. The process is a little tedious, but after a while it just becomes natural. Like hitting the snooze button six times in the morning . . .
Text editor powered by tinymce.