SparkFun Forums

[robin_hodgson]

Well, I just spent a day getting to the bottom of this, so I'll try and save someone else some trouble:

If you have reason to need to execute the IOM HAL code while debugging your application, you may encounter situations where IOM transfers that look like they should be working are actually failing due to IOM IACC (Illegal Access) and FUNDFL (FIFO Underflow) errors. To make things worse, there seems to be no way to get rid of those errors: even manually writing the IOM's INTCLR register won't make them go away.

I finally figured out that was the debugger causing the problem. As you are single-stepping, if you are displaying the IOM register window, every time the debugger stops, it will read all the IOM registers so it can update their contents. However, a read the FIFO register pops it, even if it is the debugger doing the reading. This debugger read will cause the FUNDFL underflow, which then generates the IACC error.

To fix this, you need to edit "am_hal_iom.c". Find the line that says:

Code: Select all

#define MANUAL_POP  0

and change it to:

Code: Select all

// Allow the debugger to read the FIFO without popping it
#define MANUAL_POP  1

This tells the HAL code to not use the IOM's auto-pop-after-a-read feature. Instead, the HAL software will generate explicit 'pop' requests after reading the FIFO. Under those circumstances, the debugger will be free to read the FIFO register without disturbing it.

The only downside is that the HAL driver needs to do 1 extra write for every 4 bytes that get removed from the IOM interface. It shouldn't be a big deal. And if it is, well, you shouldn't be using the HAL in the first place

Hope this helps someone!

[liquid.soulder]

Nice detective work! This will be good to have tucked away in the 'ol cerebral cortex-m.