topic Re: OM13098 SD-RAM issues ... in LPC Microcontrollers

OM13098 SD-RAM issues ...

frank_m — Mon, 27 Jul 2020 13:32:03 GMT

I am having a bit of a difficulty with the external SDRAM on the OM13098 board (LPC54628).
My application is basically an event recorder, that samples a fixed amount of input data for a certain time, and stores them to SD card afterwards. For size reasons, I want to store the input data in SDRAM.

My first, less elegant approach was to assign a fixed address (0xA000.0000) to a pointer variable.
That works partially, but I'm having some strange problems.
The input data (several channels) are gathered via ADC interrupt, and written to the SDRAM buffer.
If I step into the interrupt handler, I can see plausible values, and they are written to the proper SDRAM addresses (checked in the debugger).
If I step over the data collection function (which just enables the trigger for timer & ADC, and waits for a ready flag), the SDRAM buffer is empty afterwards, i.e. contains the all-zero initialisation values (check the "Memory" view in the debugger, set to the given address).
Respective data types are all "volatile".
To debug and test other parts, I use the internal RAM temporarily, which is filled to 80% ...

And, checking the MCUXpresso help, there seems a more elegant way I currently explore.
When including cr_section_macros.h, I can use the sections provided in the linker script, which already include the SDRAM.
Since the SDRAM does not "exist" during startup, I need the __NOINIT macro, I suppose.
So, something like this:
__NOINIT(BOARD_SDRAM) uint16_t my_buffer[SIZE];
Confusingly, the map file contains (empty) sections for SD_RAM code and data which are not ".noinit".
Wouldn't such initialisations fail catastrophically if no EMC/SDRAM init preceded the startup memory initialisation ?

Perhaps someone experienced with the MCUXpresso toolchain can shed some light on this issue.

Thanks,

Frank.

Re: OM13098 SD-RAM issues ...

frank_m — Tue, 28 Jul 2020 11:38:05 GMT

It seems I fell into the ad-hoc project generation trap again.

The SDRAM example from the SDK worked fine, so I knew it's not the hardware.

My current project is derived from the SD/FatFS example.

So, I copied the EMC init code, but forgot about the pin mux initializations ...

Re: OM13098 SD-RAM issues ...

frank_m — Wed, 29 Jul 2020 14:55:25 GMT

Adding the proper pin mux initialisation helps, the application than works as expected.

I still don't fully understand what the debugger had been showing me. Writing three 16-bit words in short succession to the SDRAM, the debugger (memory window at 0xA000.0000) showed a proper value directly after one write.

But with the write to the next address, the value was "gone", i.e. changed to zero.

Perhaps the EMC peripheral is routed via an internal buffer.

Re: OM13098 SD-RAM issues ...

Sabina_Bruce — Thu, 30 Jul 2020 16:55:45 GMT

Glad that you were able to resolve the issue. I am not sure what those values may have referred to.

If its possible to reproduce on the evaluation board please share your project. Include the changes before and after you are seeing this and what memory range you were able to see values.

Best Regards,

Sabina

Re: OM13098 SD-RAM issues ...

frank_m — Mon, 24 Aug 2020 05:58:57 GMT

I am not sure what those values may have referred to.

My "issue" was that the debugger (memory view at 0xA000.0000) did show seemingly correct values (at 16 bit writes).

After another write to the EMC (different address),the previous value was reset to zero.

I suppose the EMC interface has some transparent caching mechanism that fooled the debugger - I might need to study the appropriate MCU manual section in detail ...