DSP16 Absolute Value causing Data Address Read Exception

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Part: AT32UC3A3256

Library: AVR-UC3-SoftwareFramework-1.7.0

 

I have an issue that causes the micro to enter a processor exception loop at _handle_Data_Address_Read. I traced it back, according to the link register, a couple times to the same line:

dsp16_vect_complex_abs(output, input, sizeOfInput);

Input and output in this case are both A_ALIGNED. Input is type dsp16_complex_t and output is type dsp16_t. Both variables are memset in the constructor to 0.

 

However, the micro enters the exception loop in the middle of a UART transmit, always, which would leave me to believe that this isn't the line that got the processor into the exception loop but it may still be the root cause. UART transmits are done through a FIFO buffer and interrupts are disabled before transmitted or receiving. The receiver of the UART is doing everything correctly as far as I can tell.

 

This interesting part of this problem is it's only an issue on some micros, others run fine without issue. Three micros that were experiencing this issue were swapped onto boards that were known to be working and the problem followed the micro. I have contacted MicroChip who says this is definitely a software issue because they would hear from more customers if it was a hardware issue. From my prospective, it's a hardware issue that is brought to light by a perfect storm of timing and software.

 

Couple more interesting notes:

  • The disassembly shows the use of ld.h and st.h but the documentation for this micro shows that it can only use ld.w and st.w. I'm unsure why the build would use those instructions if they can't be used or if the documentation is incorrect.
  • I've read that the dsp16 library uses modulus addressing extensively but problems can be avoided by aligning variables, which I do.
  • Just about any change to the code, even the program trace code or changing pow(x,2) to x*x, will stop this error but only on some micros. So, in theory, I can make some random change and make this go away but I'm trying to solve this problem not just push it down the line.
  • There is no errata that appears to pertain to this setup and situation.

 

I can not post the code but I will answer questions to the extent that I can.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ld.h ? There are ld.sh and ld.uh instructions, check the hex opcodes in your dissasembly against the 5 formats.


My suspicion is your stack is being trampled, either because there is not enough of it, or because of a buffer over/under run.