topic M4 MQX application too large for SRAM in Vybrid Processors

M4 MQX application too large for SRAM

jbs — Mon, 20 Oct 2014 21:30:44 GMT

My M4 MQX application may become too large to fit in internal SRAM soon. What options are available if this happens?

Re: M4 MQX application too large for SRAM

bfac — Tue, 21 Oct 2014 10:05:59 GMT

Hello JBS,

Considering you are already using the DDR for the Cortex-A5 side (possibly Linux), you still have the possibility to run code on the Cortex-M4 from the QSPI module with the XIP (execute in place) function.

Please check the VYBRIDRM.pdf (rev 7) on "Chapter 30 Quad Serial Peripheral Interface (QuadSPI)" you will get an idea on the solution.

The Vybrid Tower (Vybrid Controller Solutions Tower System Modu|Freescale) has 2 QSPI devices, this might be a good reference, there might be examples available.

BR,

Bruno

karinavalencia

Re: M4 MQX application too large for SRAM

jbs — Tue, 21 Oct 2014 15:06:42 GMT

Thanks for your reply! Can the MQX image live in NAND, then be copied to DDR and execute out of there, or would that be opening a can of worms? We are running linux on the A5. I saw a post in the Kinetis forum that seemed to indicate that MQX doesn't particularly like to run out of DDR. Are there any other options besides QSPI?

Re: M4 MQX application too large for SRAM

bfac — Tue, 21 Oct 2014 15:34:32 GMT

Hello JBS,

I believe you can run M4 from DDR, but the problem will be the possible wait states as you will be charing the DDR bus with both processors and other peripherals.

Usually, customers need to guarantee the M4 application will be real time and deterministic; and having the possibility of not having the bus ready at any time might be an issue on those cases.

Anyway, if you want to test that, I would suggest you to run instructions like these from uboot or linux:

(Please notice these are only examples, and you will need to change the addresses, they most probably are pointing to internal SRAM).

From uboot:

setenv bootcmd 'fatload mmc 0:1 0x81000000 uImage-3.0-ts-armv7l;fatload mmc 0:1 0x3f000000 oobe_twrvf65gs10_m4.bin;mw.l 0x4006e028 0x3f000485;mw.l 0x4006b08c 0x00015a5a;bootm 0x81000000'

From Linux:

modprobe mcc

mqxboot pingpong_example_twrvf65gs10_m4.bin 0x3f000000 0x3f000485

Other possibilities are:

Having an SRAM connected on the Flexbus and running from there.

The QSPI should be also compatible with QSPI DDR RAMs, instead of Flash (not sure if it helps anything).

BR,

Bruno

Re: M4 MQX application too large for SRAM

jbs — Tue, 21 Oct 2014 17:02:04 GMT

Thank you much

Re: M4 MQX application too large for SRAM

jackblather — Tue, 21 Oct 2014 21:13:22 GMT

Will the M4's caches cache instructions and data fetched from DDR?

Re: M4 MQX application too large for SRAM

bfac — Tue, 21 Oct 2014 22:03:25 GMT

Hello Jack, I would believe so, but I prefer to ask the core device experts.

karinavalencia, can you help us getting in contact with a Vybrid core expert, to answer Jack's question?

Re: M4 MQX application too large for SRAM

karina_valencia — Tue, 21 Oct 2014 22:51:08 GMT

cyborgnegotiator can you help to answer last question? Will the M4's caches cache instructions and data fetched from DDR?

Re: M4 MQX application too large for SRAM

cyborgnegotiato — Tue, 21 Oct 2014 23:35:26 GMT

Hi,

Yes, M4 has L1 cache and can cache instruction and data from DDR (and other non local memories).

For code in DDR you can use DDR code alias address range - this increase performance too (M4 fetch code via Code cache, opposite to System cache).

For more details please read Vybrid RM, especially chapter 29. Local Memory Controller, and look to Table 29-1. Address Space Decode.

Regards,

Jozef