Code crash repetitively at same address

benoitstjean · Posted: Thu May 02, 2019 12:19 pm

Device: PIC24EP512GP806
Compiler: 5.026

Alright, this is a very long shot but I figured I'd try to see if anyone can help...

I sent an email to the SD driver company (Brush Electronics). Mr. Smallridge from Brush Electronics is usually good and fast at responding but I'm giving a try here as well just in case...

My PIC is sampling 64kbps PCM data from an audio CODEC and saving it to an SD card using his driver. I have used this driver to save slow data during the past 4 years and it has always worked. Today is the first time I try with the audio. The recorded audio sounds as expected and works fine, however, there's something happening that the driver does not like and I have had 4 crashes today while saving data to the SD card, three at the same address and one at another address.

The three at the same address occured after roughly 2 minutes of data being written. I was, however, able to record successfully 3 minutes of audio in one instance without a glitch. So I have no idea why the crash occurs.

A few years ago on this site, I was given a little piece of code to capture the address of where the address trap occured and this code is inside the address trap interrupt. I was told that the crash occured at the address immediately _before_ the reported address.

When I tell the compiler to put the code in assembly, the address the trap interrupt returned is 0F5D8 therefore I would assume that the crash would occur at 0F5D6. Here is the ASM code of the function in questions (excerpt from the driver code):

wcnt = 512 - ((WORD)(fp->fptr) & 0x1ff); // Copy fractional bytes to file I/O buffer
if (wcnt > btw)
wcnt = btw;

memcpy((void *)&fp->buffer[(WORD)(fp->fptr) & 0x1ff], (void *)wbuff, wcnt);
fp->flag |= FA__DIRTY;

The ASM code below is what CCS provides in the .LST file. This code immediatly follows the last line above (fp->flag |= FA__DIRTY;):
0F5AC: MOV 5B96,W0
0F5AE: MOV #1A,W4
0F5B0: ADD W4,W0,W5
0F5B2: MOV.B [W5],W0L
0F5B4: IOR #40,W0
0F5B6: MOV.B W0L,[W5]
0F5B8: MOV 5BAA,W0
0F5BA: MOV 5BA6,W4
0F5BC: ADD W0,W4,W0
0F5BE: MOV W0,5BAA
0F5C0: MOV 5B96,W0
0F5C2: MOV #0,W4
0F5C4: ADD W4,W0,W5
0F5C6: MOV 5BA6,W0
0F5C8: MOV [W5],W4
0F5CA: ADD W4,W0,[W5]
0F5CC: MOV [++W5],W4
0F5CE: ADDC W4,#0,W4
0F5D0: MOV W4,[W5]
0F5D2: MOV 5B9C,W5
0F5D4: MOV 5BA6,W0
0F5D6: MOV [W5],W4
0F5D8: ADD W4,W0,[W5]
0F5DA: MOV 5B9A,W0
0F5DC: MOV 5BA6,W4
0F5DE: SUB W0,W4,W0
0F5E0: MOV W0,5B9A
0F5E2: GOTO F33C

The second (different) problem is at address 0EA54 with the ASM code below function <f_write> at the line indicated below:

fp->curr_sect = sect;
0EA4A: MOV 5B92,W0
0EA4C: MOV #10,W4
0EA4E: ADD W4,W0,W5
0EA50: MOV #5B9E,W4
0EA52: MOV [W4++],[W5++]
0EA54: MOV [W4++],[W5++]

Again, I know this is a long shot and perhaps the code above does not mean anything to anyone therefore it's not a big deal but I have no idea how the assembly code works so maybe someone out there will understand and shed some light.

Thanks for your time!

Ben

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

Before we waste time, what is the address offset used by the code you have
to access the error address?. CCS changed the design of the interrupt
handler a while ago, and the latter compilers need a different address to
older compilers. Lets just make sure you are using the address for your
compiler version....

Now obviously everything here is dependant on fp genuinely pointing to the
right address. Triple check anything that sets/changes fp.

benoitstjean · Posted: Fri May 03, 2019 4:51 am

Hi TTelmah,

Actually, I got a lightning fast response form Andrew at Brush Electronics yesterday.

His suggestion is to try a 4GB-32GB card to force the driver in SDHC mode which will probably circumvent that issue. I did not realize I was using a 2GB SD, I just grabbed whatever I had kicking around without really paying attention to its size.

Andrew's response sums-up to:

My suspicion is that the issue will be related to pointer arithmetic and how it is handled differently between different versions of the compiler. I don’t know if it will solve the problem (using a 4GB or greater card) but it will force the code through the SDHC path. I still think it is a compiler related issue that is exposing an existing bug in the driver that was not previously visible or it is introducing a bug. The pointer handing between the PCH and PCD version of the file system differ only be the WORD alignment forced by the processor. This translates to a difference in pointer handling and therefore pointer arithmetic however this code has not been changed in years.

So if that's the case and solves the issue, although it may or may not help anyone here, I'll still post it here in case anyone else uses that driver for PIC24 and encounters some weird unexplainable random issues.

I have many versions of the compilers between 5.026 and 5.071 but all versions above 5.026 caused many problems at compile time, introduced bugs, handled memory horribly (even to the point I could not compile the code) so I opened a ticket with CCS and their suggestion was to stick with the 5.026 compiler in the background but use the 5.071 IDE. The reason I wanted to use the 5.071 IDE is because of its __BUILDCOUNT__ option which is not available in 5.026. So at the moment I have a bastardized CCS version which works well for me.

Not sure what's the new compiler version now but I don't want to buy it only to realize afterwards that it's worse.

Thanks for your time.

Ben

jeremiah · Joined: 20 Jul 2010 Posts: 1354

A little late to the party, but for PIC24's I like to do the trap address check a little more generically so that there is less chance for compiler differences to occur:

benoitstjean · Posted: Fri May 10, 2019 5:57 am

Well, I guess that I didn't get to really "fix" the issue other than it went away on its own after analyzing how I was handling the data and shuffling stuff around. I trust more the driver code than my own!

At the time this error occured last week, I realized afterwards that there were a few things I was doing wrong when handling the data and manipulating files.

We are a week later and since Tuesday, I've been analyzing my own code and I can confirm that I am no longer getting the crash therefore it really was something in my code.

So now I can record audio to SD card without a problem for as long as I want or reach the end of the card.

Sorry if I can't provide a clearer answer to my own problem in case anyone else runs into the same issue.

Thanks to both of you who responded.

Ben