I'm bringing up a custom BSP on a Cortex-M4 and have gotten to the point where I'm sending audio through a simple test layout:
After 123 samples, I'm getting a hard fault within awe_fwGetClassType. The only other post I've found about a similar crash had to do with block size mismatches, but my block sizes all match.
How do I fix this?
4:09pm
Most likely this crash is being caused by something not quite in the background housekeeping thread (the call to awe_fwTick()). As a first step, comment out your call in the main loop to awe_fwTick() to see if the problem goes away. The problem is usually caused by memory corruption of the underlying Audio Weaver heaps and structures.
5:13pm
Paul,
Thanks for the response. That was the clue I needed and I figured out what was writing to the wrong memory locations.
9:52pm
Now that I've gotten past that issue, I'm having a much stranger one. I added a line of code in an unrelated thread (and it doesn't even get executed before this issue occurs), and now awe_fwTuningTxByte() always returns "done" even though there's a reply to send out. This, of course, results in the server not being able to connect.
The only observable difference is the location in memory of all of the code following the function with the extra line. So, for example, awe_fwTuningTxByte moves from 0x100890C8 to 0x100890E8.
Since I obviously don't have source code for the framework libraries, it's pretty much impossible to find out what's going on here, so any help debugging this would be appreciated.
Thanks.
11:40am
Hi,
The return of awe_fwTuningTxByte will always be true if the internal message state is out of range, which can only happen if the state gets corrupted. This suggests that there is an invalid pointer or an array overrun somewhere in the application even when tuning does appear to work, and it's just that moving the memory around a bit is revealing the issue.
I'll let you know if we think of any different causes or other ways to help debug this.
Thanks
-Axel
12:32pm
Axel,
I just want to point out that the only things moving around in memory here are in flash, and the RAM memory map stays the same.
1:21pm
There is one more possible thought. The transmit and receive state machines use the same state word. On receipt of the transmit end byte from the host, the state machine is placed in the state waiting for response state. This state is required to arm the transmitter to begin sending.
If 0x03 (ETX, end of received message) is never received by awe_pltTuningRxByte(), then the transmitter never becomes armed. In short, the RS232 protocol is half duplex, and can only reply after receiving a valid message to reply to, similarly transmitting a complete message places the machine in the state ready to receive next message. All our serial messages start with STX (0x02) and end with ETX (0x03). All our packets including the start and end have a length of 3+5*N bytes where N is the number of 32 bit words we sent.
Can you try printing the received packets to make sure you are receiving the correct start and end bytes? You can compare your received packages against the packets in Bin\win32-vc100-rel\logs\packet.log. If this file doesn't exist, make sure you have the following section in your Bin\win32-vc100-rel\AWE_Server.ini file.
[Logging]
Enable=1
PacketLog=1