Firmware compiling without errors but not flashing?

jazbaatbadalgaye

For the last few days I have been making some changes to the firmware to print out certain key variables in the debugging log and had been making some progress. However, today when I compiled the firmware (after adding stuff to it), it compiles juts fine (0 errors or warnings) but when I flash the firmware using Bossa or M997, the Duet board seems to go in a boot-loop (the wifi module's blue light and the Diag light keep flashing and the PC keeps making the sound when a USB port is plugged/unplugged)

alankilian

@jazbaatbadalgaye

What was your last change?

Have you increased RAM usage a lot?

gloomyandy

@jazbaatbadalgaye That is what happens when the board throws an exception (which in turn will cause a hardware reset). One of your changes will be causing the problem. You have a few choices....

Hook up a hardware debug tool and use it to trap on the exception.
Revert back to an older version run M122 and then use the stack trace that is included along with the map file for your build to identify where the exception is being thrown.
Back out all of your changes and add them back in one at a time until you identify the cause of the problem.

Welcome to the world of embedded programming...

jazbaatbadalgaye

@alankilian I am just adding some arrays of size 30 and 7. I would like to use vectors but whenever I used my_vector.push_back it does not even compile.

jazbaatbadalgaye

@gloomyandy said in Firmware compiling without errors but not flashing?:

I am going to go with no 3 for now but would be interested in learning more about #2. Could you please tell me more about it?

dc42

@jazbaatbadalgaye does the red LED flash in a particular pattern when you start the Duet?

gloomyandy

@jazbaatbadalgaye

The simple answer is take a look at this tool: https://github.com/Duet3D/RepRapFirmware/tree/3.4-dev/Tools/stackanalyzer which in theory will do some/all of the work for you.

However I've never used it (not sure if it works for the lpc/stm32 mcus that I use) or any of the other more sophisticated ways to do this (if I want that I use a debugger), instead I go "old school" as described below:

First of all you need to be familiar with the code layout in memory on your mcu, in particular you need to know what the address range is of the code part of your image in flash memory. You can get this from either looking at the .ld file used by the linker or by finding it in your .map file. You tend to become very familiar both with the map file layout and the various memory ranges when you work with firmware on a particular mcu.

One you know that address range you need to look at the output from m122 after a crash, this will contain a partial stack dump. Now examine the items in the stack dump and look for values that are inside of the address range of your code. Once found load up the map file into your favourite editor and find the section that lists the symbol names for your code along with the address they have been placed at by the linker (usually in a "text" section). You may then be able to locate the address you have from the stack dump, it will almost certainly not be a perfect match (as the map file just contains the start address of the functions), but it should be good enough to tell you the likely function (which is the function that has the highest load address that is below your selected address). You can also get a rough idea how far through the function the location is by comparing the address to the start address of this function and the next. Then look at the next entry in the stack dump that seems to be a code address and repeat.

From this you will be able to get a rough idea of what the call stack looks like and this will often let you work out what was going on when the crash happened.

There are a few things to be careful of, first of all the "address" you are looking at may not be an address at all it could just be a variable that happens to contain a value that looks like an address. It is usually easy to ignore these once you get to know the typical call sequences of the code you are working with. Secondly some of the addresses may be the part of the call stack that is actually dealing with the exception handling, you need to ignore these are work through the stack until you get to code actually doing some work. Finally sometimes the stack is totally corrupt and there is nothing of real value to be gained, in which case you need to find a different way to approach the problem.

At first this will all seem very tedious and complex and error prone (and yes it can be). However after doing it a few times it becomes much easier and you sort of get a feel for things.

If you are not comfortable working at this low level of hex addresses, stack frames and register contents, you may want to invest in a hardware debug tool (or simply not bother with embedded devices!). I'm not sure about the mcu used by the duet, but for stm and lpc based devices you can use one of the many st-link clones that can be had for a low price. However be warned these are far from perfect and the toolchain to use them (I use vscode, gdb and openocd) can be complex to setup and make work. There are much better commercial solutions, but these tend to cost a lot more....

Good luck

jazbaatbadalgaye

@dc42 I just sort of blinks when the SD card is not inserted and when SD card is inserted, it blinks furiously. I reverted back to 3.3 and making changes in there.

dc42

@jazbaatbadalgaye if it blinks furiously then the board is crashing shortly after boot up. If you load known working firmware then you can use the M122 report to find the crash address.

jazbaatbadalgaye

@dc42 That is exactly what is happening. It crashes as soon as I flash the firmware (changed one). I will tinker with stackanalyzer tool and revert back with findings.

jazbaatbadalgaye

@gloomyandy Thanks for the link to the tool. I will definitely have to do a lot of reading and learning but hopefully it will be worth it. I will tinker with it and revert back with updates