GCC w/ LPC2378 and jump alignment problem?

So, I have an Olimex LPC-2378 dev board and have been doing some work on this for while now. I’ve been fighting an issue with it where it would randomly trigger the prefetch abort exception (usually within 30 seconds of running and sending data to it over the uart, which triggered most of the useful processing). I had also encountered cases where it would execute the “else” clause of an if-then-else block, even though it had also (correctly) executed the “if” part of the block. So, I started poking around and finally tried setting -falign-jumps=4, and voila, it started working reliably.

The arm7tdmi-s spec says that instructions need to be 16bit aligned for thumb, and 32bit aligned for arm. But this kind of thing should be handled by defaults in the compiler right? In all the other sample makefiles I’ve seen, I have not seen anyone use this option to get their code to work. Has anyone else experienced similar issues? Is there something totally different that I’m missing or am not considering?

Partial Excerpt of GCC command:

arm-elf-gcc -c -mcpu=arm7tdmi-s -O3 -gdwarf-2 -mthumb-interwork -mthumb -falign-jumps=4 -fomit-frame-pointer -Wall -Wstrict-prototypes -fverbose-asm

note: gcc version is 4.2.1

Thoughts?

Thanks,

-Dave

Very strange, the 16bit alignment should be ok.

Could it be something related to the MAM settings ? wrong clock settings ? wrong wait states settings ?

You may try to run the code from RAM and see if it is a flash-related problem.

I never tried the LPC-2378 but the LPC-2148 should be similar and I never had such problems with that chip using GCC (YAGARTO).

I have not been able to get it to work reliably except with MAM_CR = MAM_CR_PARTIAL and the CPU at 48 MHz (NVAL=0,MVAL=11,CPUCLKDIV=5).

It seems this is likely a well-known problem, you could try the above settings or no MAM to see if that helps. The problem occurs only with certain code alignments so it can be difficult to reproduce reliably.

Dan

Thanks for the feedback. I’ve been investigating some of the things you mentioned. Among the interesting discoveries are the following:

Under original PLL/MAM configuration (NVAL=0, MVAL=11, MAM=OFF, CPUCOLOCKIDIV=5)

-if I set -falign-jumps=2, I get identical binary output as not setting -falign-jumps at all

-If I try to set MAMTIM to anything other then 7, it prefetch aborts almost immediately on boot

-The insertion or deleting of almost any c-code to the program changes when and how likely the error occurs.

I’ve done quite a bit of work with FreeRTOS on the LPC2148, and have not had these issues with it. It seems very unlikely to me that it’s a GCC issue. I think the various instruction sequences that GCC creates are more or less likely to trigger the underlying chip configuration problem.

So, given the above, I changed my CPU_CLOCK_DIV to 10 instead of 5. After doing so, the code that had been running previously and crashing started working perfectly. I ran a test application against it for 8 hours and it worked perfectly, no prefetch aborts.

On a side note: modifying the M and N values such that the CPU speed was effectively cut in half had the same reliability improvements.

Also, after lowering the CPU clock speed, I was able to configure the MAM with 3 wait states and turn it on in partial mode, no crashing.

So, I think I at least have an understanding of the issue now.

Has anyone else had issues running this chip at higher speeds? The data sheet says up to 72mhz, and I’m running about half that right now.

Thanks for the feedback everyone, much appreciated :slight_smile:

Have you looked at the errata? Some chips have a MAM problem at higher speeds.

Leon

Wow, so, I ended up tracking this down to having a CCLK divisor that was not an odd number or zero. The manual says that this value must be 0, or odd, else unexpected behavior could occur. The code I have was doing some #define trickery, so when I put in an odd number, it did some math to make it an even number. Every since I fixed that, all my random problems have gone away… It would be nice if they did something like abort exception the CPU when you try to put in an illegal value, or define it such that you can’t put in an illegal value. That’s probably too much to ask for. Hope this helps someone else…

Regards,

-D