Issues accessing external SRAM via FlexBus (on MKV58F1M0VLQ24)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Issues accessing external SRAM via FlexBus (on MKV58F1M0VLQ24)

3,224 Views
JulianS
Contributor II

Hello,

In the past weeks I spent a lot of time accessing and testing external SRAMs (IS61LV25616AL) via FlexBus on my custom pcb with the Kinetis MKV58F1M0VLQ24. I wrote my application with the use of the SDK version 2.7.0.

In general, I need an extern SRAM to extend the internal RAM size of the µC, especially for relocating data / variable constructs.

As a reference for the pcb design, I mainly used the schematics from the TWR-MEM board from NXP as well as the Application Note for FlexBus on a Kinetis µC. On our pcb, I am able to access up to 4 different SRAMs of the previous mentioned type by 4 different chip selects, all of them persisting on the flexbus interface to a single µC.

As an example, I will attach one of the SRAMs on the flexbus in this post (SRAM schematics.PNG). For simplicty I will reduce my description to this single SRAM, ignoring the other SRAMs on the bus.
You can see, that I am using the SRAM without a byte lane shift with the 8-bit port size. Accordingly no latch is requried because I am using the non-multiplexed control.

In my application, the relevant control can be comprehended in the attached files:
clock_config.c: clock configuration, designed in the clock configuration tool from NXP
PinMux.c: the for this SRAM control needed pinmuxing in my application
flexram_ld.txt: an extract from my linker definition file regarding the used SRAM
FlexRAM.c: my FlexRAM initialization for the mentioned SRAM, exrtended with the flash-to-sram copy mechanism for the usage of relocated data.

My first question about this whole topic is:
Can you confirm the correctness of the way I am controlling the SRAM regarding the pcb design as well as the code I attached?

 

Furthermore I will tell you about the result of my own testing in order to ask my second question.
As a first step to test my SRAM I wrote a testfunction that goes through each address of the SRAM, writing pseudorandom values to my memory (generated by a shift register like a lfsr). After a couple of seconds the functions reads each addres of the SRAM back and compares the result to the previous written value. I implemented the testfunction with 1byte, 2byte and 4byte accesses and moreover varied the SRAM access from linear address incrementation to random access.
The result: each of the tests succeedes without any error!

Up to now, I thought I implemented everything in the correct way, but sadly this is where the problems began. The next test was the use of the SRAM as it was meant to be used: relocating data constructs from flash to my SRAM (and using those constructs in my general application).
I started relocating teststrings to my SRAM:

__attribute__ ((section(".flex_RAM")))
static const char FlexRamTestString[] = "Hello World, this is a test for the FlexRAM interface...";

And I had absolutely no issue with that. Reading from this variable always succeeded without any error.

The "fun" began when I relocated structs from my inner application (filled with function pointers, variable pointers, buffers and lots of stuff my application uses). Running my application solely in the µCs internal RAM works like a charm, but as soon as I relocated some of the structs (in that case variables concering UART and Ethernet communication and overlaid protocols of my own), my applpication starts crashing with usage faults in numerous different ways. I had usage faults with unaligned access, invalid state and bus faults.
I analyzed the crashes either with my own exception handler (storing the µC registers and exception information) as well as with my PEMicro cyclone universal FX debug interface.
Especially using the debugger I became highly sceptical, as the application crashed for example on executing a function pointer that persisted on the external SRAM (the function itself does not persist in the SRAM, only the function pointer in the relocated struct!). The application crashes with a usage fault, because the function pointer is either zero which leads to the invalid state fault, or it is a value far from the correct function pointer address which leads to a bus fault. The strange thing here was, that when I checked the memory with my debugger where this function pointer persists in the SRAM, everything seems correct, as the stored address equals my expectaton.
I observed multiple faults of those kind in my whole application that uses variables that where relocated to my SRAM. Another one for example where unaligned accesses which never every occurred using the application solely with the internal RAM.

So finally I will come to my second question:
Does anyone have an idea what could cause such behaviour? For me it seems like in the context of my application running, there are faulty SRAM accesses which lead to those usage and bus faults, but I am not able to investigate those errors, as it seems to be only a volatile error state that is not really observable. Sadly I have no suitable logic analyzer to observe the problem directly on the hardware.

I varied the flexbus configuration multiple times in order to attach numerous wait states and hold cycles, I reduced the flexbus clock rate and even the clock rate of my µC but the errors always keep the same. To be honest, I'm not assuming that the flexbus timing plays a major role herem as the used SRAM is a very fast one.

Currently I am at my wits' end and I hope to find some help here...

kind regards,
Julian

0 Kudos
2 Replies

3,175 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi Julian, I hope you're doing well!

 

Unfortunately, due to this being on a custom PCB, our ability to perform tests is reduced as we do not have access to your hardware.

 

Is it possible to try replicating this behavior using the TWR-MEM board and our KV58 development kit?

 

Please let me know of your results.

 

Best regards,

Sebastián

0 Kudos

3,170 Views
JulianS
Contributor II

Hello Sebastián,

Thank you for your response!

I don't know if the same behaviour can be observed on the Evaluation-Boards from NXP, as I currently don't have access to any of them.

The application I am running consists of different libraries and I am not able to publish anything of it here. If nobody has any idea what could be the cause of this problem, I could try to write another application, based only on the NXP Kinetis SDK.

But at first I hoped someone can confirm my memory initialization process / control in software regarding my electrical design (first question in my initial Post).

 

Kind regards,

Julian

0 Kudos