Multicore M0 app and memory selection

[lpcware]

Content originally posted in LPCWare by g_mocken on Fri May 30 02:49:30 MST 2014
From the FAQ I understand that I need to specify the same M0 memory configuration for both M4 master and M0 slave project.

For the M4 master project, there is a simple drop down list to choose from.
For the M0 slave, I do not see any options to choose from - there only is the entire memory map under MCU settings, but no obvious way to choose into what section the M0 code should go.

I tried various combinations of settings and both the sample code "mc_sa_blinky_xxx" and projects created from scratch. I always either end up with the compilation error "M0APP execute address differs from address provided in source image" or with a binary, that does not contain the M0 code at all (the sample code then outputs "Unable to BOOT M0APP Core!" on UART and the debugger shows no code in the related memory location).

Note that I am using two LCPLink2 boards with 4370 (so I have external Flash), one of them as probe and the other as target.


Other (single core)  sample codes run fine, but here I also do not understand, how the target memory location can be customized.

Can you help?

Guido

[lpcware]

Content originally posted in LPCWare by r1200gs on Wed Nov 05 14:34:57 MST 2014
Thanks very much for the 3core blinky demo you attached above.

There are so many no longer relevant web pages and examples that don't work that it is really hard to get multicore stuff working on the 4370.

Just wanted to say that I, too, got your 3core blinky demo to run, and then the DEBUGOUT() printf support over SWO for multiple cores at once running,
by uncommenting defines for DEBUG_ENABLE and DEBUG_SEMIHOSTING in board.h (for both m4 and m0 board.h's) on a pair of Link2's while linking
the semi hosting Redlib.

Then when I went back to run the ROM USB stack via libusbdev.c from the usbd_rom_libusb example in lpcopen 2.12 on the m0app it suddenly started working rather
than crashing as it does without the debugging enabled.

Reducing the problem from 'some error somewhere' to 'mostly likely a call timing issue' has been a huge step forward.

I would like to suggest that an example that shows a multicore usbd_rom_libusb (i.e. running the USB stack from m0app) would be an excellent demo for lpxpresso.
It frees the M4 up for real time DSP stuff while providing low overhead high speed USB connection to a host.

[lpcware]

Content originally posted in LPCWare by g_mocken on Thu Jul 17 03:00:25 MST 2014
Thanks, I now have all three cores sending their output into separate console windows using Redlib(semihost) only.
For some reason, I still had DEBUG_SEMIHOSTING commented out in my board.h.

Now, for performance reasons, I would like to send the M4 output to UART while keeping both M0 outputs in a "semihosting" console. Is that possible?

Do the M0 slave projects actually use the library specified for them, or are they re-linked to the master project's library (or vice versa?) when they are inlucded into the master image?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Jul 16 08:21:06 MST 2014
From a quick scan, it looks like the debug i/o retargeting layer in LPCOpen does not support Newlib - only Redlib (which I'll discuss with the LPCOpen team).

That aside, you need to go read this FAQ:
http://www.lpcware.com/content/faq/lpcopen-debug-inputoutput-support

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by g_mocken on Wed Jul 16 03:08:24 MST 2014
Thanks, I can compile, run and debug all three cores now.

I could still need a little help regarding Semi-Hosting, because with three independent cores, one does not want to print everything to the same physical UART.

In the sample code, I can switch M4 and M0app to NewLib(semihost) and get the desired behavour (serial output in separate console views), but for M0sub, there is not enough memory to do the same. NewLibNano(semihost) fits and compiles, but runs into HardFault immediately. RedLib(semihost) also fits, compiles and runs, but then sends the output to UART instead of the console (this last point is not specific to the multicore setup discussed here).

So is there a way to make semihosting work in either NewLibNano or RedLib, or do I have to change the memory configuration in order to make NewLib(semihost) fit for M0sub?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Jul 15 05:55:12 MST 2014
I've now modified the LPC4370 LPCOpen 3 core blinky example to build as a "full LPCXpresso multicore project" - and attached to this post. You will need to ensure that the board and chip libraries have been imported into the workspace too in order to build these.

The main change done beyond what documented previously in post 3 was to replace the calls into the LPCOpen function call to release the M0 cores from reset (M0Image_Boot) with calls into the similar function generated by the LPCXpresso new project wizard (cr_start_m0). The LPCOpen functions make assumptions about memory layout that are not true with the modified projects.

I've tested this on hardware here, and all is running as expected.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by g_mocken on Tue Jul 15 05:07:58 MST 2014

---

Quote: lpcxpresso-support
Is there any reason why you are not using LPCXpresso IDE to download and debug your applications?

---

But I am using it all the time ... just updated to latest 7.3.0 this morning.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Jul 15 04:11:16 MST 2014
Actually, that isn't quite correct - commenting those lines out completely will stop the M0APP and M0SUB being booted at all. I'll post a follow up later today when I've had chance to experiment some more.

Regards,
LPCXpresso Support.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Jul 15 03:57:46 MST 2014

---

Quote: g_mocken

---

Quote: lpcxpresso-support

[... ]You should now have projects the build and run...

---

I followed all the steps to the letter, but I am still getting the same result:
"Unable to BOOT M0APP Core!" on UART and the debugger shows no code at BASE_ADDRESS_M0APP.

---

Try commenting out the following lines in prvSetupHardware() in the M4 project:

/* Time to Start M0APP */
if (M0Image_Boot(CPUID_M0APP, (uint32_t) BASE_ADDRESS_M0APP) < 0) {
DEBUGSTR("Unable to BOOT M0APP Core!");
}

#ifdef BASE_ADDRESS_M0SUB
if (M0Image_Boot(CPUID_M0SUB, (uint32_t) BASE_ADDRESS_M0SUB) < 0) {
DEBUGSTR("Unable to BOOT M0SUB Core!");
}
#endif

They are no longer relevant with the modified project with the way that LPCXpresso is now building, downloading and executing the combined M4/M0/M0 image.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Jul 15 02:51:28 MST 2014
Is there any reason why you are not using LPCXpresso IDE to download and debug your applications? I think this will help you understand and track down you issues more quickly.

See:
http://www.lpcware.com/content/faq/lpcxpresso/lpc43xx-multicore-apps

[lpcware]

Content originally posted in LPCWare by g_mocken on Tue Jul 15 02:32:26 MST 2014

---

Quote: sundarapandian
Hello Guido,
        Please refer to this FAQ.

---

I also tried to (as suggested in the FAQ) [u]manually[/u] program the M0APP and M0SUB  (to 0x1401000 and 0x14020000).
When I now start debugging the M4, I get past those "sanity checks", but then it stops  at  HardFault_Handler() after printing "M0 Ignoring unknown message!" to UART.

[lpcware]

Content originally posted in LPCWare by g_mocken on Tue Jul 15 02:20:40 MST 2014

---

Quote: lpcxpresso-support

[... ]You should now have projects the build and run...

---

I followed all the steps to the letter, but I am still getting the same result:
"Unable to BOOT M0APP Core!" on UART and the debugger shows no code at BASE_ADDRESS_M0APP.

[lpcware]

Content originally posted in LPCWare by sundarapandian on Fri May 30 14:16:09 MST 2014
Hello Guido,
        Please refer to this FAQ. The LPCOpen dualcore/multicore examples does not have support for the steps shown in http://www.lpcware.com/content/faq/lpcxpresso/lpc43xx-multicore-apps yet. We might try to address them in the future releases.

Hope this helps.

Sundar.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri May 30 10:00:04 MST 2014
I've not looked at the LPCOpen package for LPC4370 before.... I can see that the projects are pretty broken. I will speak to the LPCOpen team and try to get the fixed (it won't be today, though)


The basic principle of how this works is as follows
- the objective is to link code for the 3 cores into separate memory areas. If you try to run them out of the same area, you will get serious memory contention and the whole system will run slowly
- We build the slaves as wholly linked executables (axf files). They are linked to run at their run-time addresses.
- The slave images are linked into the master image to create a single binary for download.
- The startup code for the m4 will copy the slave images into their linked memory region for execution

- For ANY project, the linker will place code (.text) into the FIRST Flash region defined in the memory configuration. It will place the data (.data+.bss) into the FIRST Ram region defined in the memory map. If there is no Flash region, the whole image is linked into the first RAM block. This is the reason you have to edit the memory map for the sales, to delete the memory regions you do not want used.
- For a Master project, the slave images are linked into its .text section (but as mentioned above, copied to their run-time address in the startup code).

To fix the LPCOpen projects, you will need to:
- ensure the master and 2x slave projects start by sharing the same memory map (I notice they don't...)
- in both slaves, delete the Flash region. This will cause the slave code to run from RAM
- in both slaves, ensure the RAM region you want it to run out of, is first in the memory configuration list. Also ensure they are different from each other!
- in both slaves, edit the project properties and on the Linker/Multicore page, select the appropriate slave
- in the master project, edit the project properties and on the Linker/Multicore page, ensure the Slave table is completed:
-- in the first column, ensure both slaves are checked
-- in the 2nd column, ensure you define the memory region you want it to run from (this MUST match the first item in the memory configuration list for the slave)
-- in the 3rd column, browse to the project containing the slave code and select the .axf.o file (you will need to build the slave projects before you can do this).

You should now have projects the build and run...

As I said, I will speak to the LPCOpen team to try and get this fixed ASAP.

[lpcware]

Content originally posted in LPCWare by g_mocken on Fri May 30 09:15:17 MST 2014

---

Quote: lpcxpresso-support
Using the memory configuration editor, you need to exclude (delete) from the M0 memory map the memories that you are using for the M4.

---

I tried to follow that advice, but in the M4 part of the mc_sa_blinky sample code, BASE_ADDRESS_M0APP decodes to 0x1401000, and at that location I only find 0xFFFFFFFF ... Simlarly, BASE_ADDRESS_M0SUB == 0x14020000 and it is also empty.

Disassembly of m0app:

start address 0x100801d1
Program Header:
    LOAD off    0x00008000 vaddr 0x10080000 paddr 0x10080000 align 2**15
         filesz 0x00003348 memsz 0x0000381c flags rwx
private flags = 5000002: [Version5 EABI] [has entry point]

I think that means that m0app was compiled for RamLoc72, which is top of the memory list for m0app.

Disassembly of m0sub:

start address 0x180001a9
Program Header:
    LOAD off    0x00008000 vaddr 0x18000000 paddr 0x18000000 align 2**15
         filesz 0x00003320 memsz 0x000037f4 flags rwx
private flags = 5000002: [Version5 EABI] [has entry point]

I think that means that m0sub was compiled for RamM0Sub16, which is top of the memory list for m0sub.

This kind of makes sense, but how do I now tell the IDE to initially place them both in flash at the locations BASE_ADDRESS_M0APP and BASE_ADDRESS_M0SUB as expected by the M4 code?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri May 30 02:59:46 MST 2014
Using the memory configuration editor, you need to exclude (delete) from the M0 memory map the memories that you are using for the M4. The memory configuration editor is describe in the LPCXpresso Use Guide.

Please also make sure you read the multi-core FAQs, starting, here:
http://www.lpcware.com/content/faq/lpcxpresso/lpc43xx-multicore-apps