topic Re: LPC4337 SDRAM read/write works, but crashes at different addresses in LPC Microcontrollers

LPC4337 SDRAM read/write works, but crashes at different addresses

moller — Thu, 18 Aug 2016 07:52:11 GMT

After a LONG struggle I am finally able to write and read from my external SDRAM.

My verification function goes from 0x28000000 and up. I write start_address+i and verify this for each itteration.

So far I can read/write 100 addresses with success every time. When I try 1000 WORDs it crashes 50% of the time.

What could make my code crash in this case?

Re: LPC4337 SDRAM read/write works, but crashes at different addresses

avt — Thu, 18 Aug 2016 19:31:53 GMT

What do you mean by crash? That can mean all sorts of things. Please say exactly what is going wrong? Maybe also post your code that is going wrong.

Re: LPC4337 SDRAM read/write works, but crashes at different addresses

moller — Fri, 19 Aug 2016 07:50:51 GMT

You are right about that. I will try to elaborate;

in my main.c I run a test-rutine that writes to an SDRAM address, verifies this by reading and checking the value, and afterwards writes on the serial-port

"Addr 0x%08x, Data 0x%08x, Counter %d \r\n",pData,*pData,i"

In case I should not read the right value I should get a:

"Error at address 0x%08x, Counter = %d",pData,i

When running the program like this, the last thing i see on the serial monitor is:

"Addr 0x280000bc, Data 0x55555555, Counter 47"

Right now I am trying to write and access the first 1000 addresses (4kb), so when writing on the serial-port for each itteration it stops at the 48th write/read, but not because verification of data was not successful. Instead it just stops.

When trying to write a change in software to the internal flash it fails. I need to set a jumper that halts the processor before it "crashes" so I can re-upload new software to test any changes.

I was wondering if I can access any hardfault interrupt vectors (or any failure vectors) through the j-tag interface so that I can see where in the program it crashes?

It is worth to mention that I have made a TestArray[1000] where I use the same verification function as for the SDRAM so test wether it was my test-function or SDRAM config that was making these crashes.

When I try to write data to the array, verify and serial-print the results, it does the same thing as for the SDRAM. NOW - when I do the same test but I disable my setupexternalmemory() function, it works fine!

I have also tried the SDRAM verification for the first 1000 addresses without serial-writing for each address. Before It would crash at the 48th itteration EVERY TIME. In this test I get a "sucess" around 50% af the times. The other 50% it crashes.

It seems very strange so I am wondering what in my code makes this crash. I don't know what exactly is happening to the M4 core when it suddenly stops giving serial-data and I have a hard time re-uploading new code to the internal flash.

I have attached my project to this answer

Re: LPC4337 SDRAM read/write works, but crashes at different addresses

avt — Fri, 19 Aug 2016 11:07:39 GMT

Try this FAQ

Debugging a Hard Fault

Re: LPC4337 SDRAM read/write works, but crashes at different addresses

moller — Fri, 19 Aug 2016 12:45:55 GMT

I have been looking at that. Sadly I am working in imIDE and not in LPCxpresso.

Any idea why it might crash?

Re: LPC4337 SDRAM read/write works, but crashes at different addresses

avt — Fri, 19 Aug 2016 15:44:09 GMT

sorry, I have never heard of mIDE, but if they are any good, they will provide instructions for debugging a hard fault. Hard faults are normally caused by bad addresses.

Re: LPC4337 SDRAM read/write works, but crashes at different addresses

bernhardfink — Wed, 19 Oct 2016 14:32:23 GMT

Is that issue solved? It sounds like you're running into a problem which we have seen on the LQFP packages of the LPC4300 family. Please look into the error sheet, there is a description.

Subsequent writes at high speed could cause race conditions in the silicon, breaks (like the UART printout) relax this situation somehow.

This problem does not exist for the BGA256 or BGA180 package.

Regards

NXP Support Team