Content originally posted in LPCWare by bavarian on Fri Mar 14 02:55:49 MST 2014
Hi,
The errors you get have something to do with the load process of the M0 code. The M4 software which looks for M0 code at a given place doesn't find valid code, so it does not allow starting the M0.
I don't know if the flags BOARD_NGX_XPLORER_18304330 and TARGET_SPIFI make sense in this project, I think I documented that USE_SPIFI needs to be used. Look for this string.
However, this demo was never intended to run on the Xplorer board because of missing display option.
On top of that there is not enough SRAM memory available to handle an internet radio application.
So the question is what you try to port?
Of course you can port the WAV/MP3 player part (which is running exclusively on the Cortex-M4 side) from the Keil board to the Xplorer board.
Just disable the part in the Cortex-M4 code which starts the Cortex-M0 and run the application only with the Cortex-M4. The M0 is not needed and stays in reset
Then there are a few endless loops waiting for an input from the GUI side (running on the Cortex-M0) which do not longer make sense. Remove or replace them by other mechanisms like button press.
Relocation of the code from internal flash bank #A to the SPIFI is no problem as well.
If you want to do something like MP3 decoding, then you wi8ll notice that the execution from the qSPI is not fast enough, so you need to place relevant parts of the decoder code into the internal SRAM.
If you want the Cortex-M0 to do something, then you need to locate this code in the SPIFI as well, in uVision it's done in the same way as for the Cortex-M4. Then there is somewhere in the Cortex-M4 code a define for the start address of the Cortex-M0 code, this must match with the address you have given the linker as Cortex-M0 RO code location.
If you execute with both cores from the qSPI memory, then of course the overall execution performance will be very bad, the SPIFI is then the bottleneck.
Regards,
NXP Support Team.
