RE: F29H850TU: Multicore debugging

I actually have it working now with this process. I changed the cmd files for both CPUS to have all flash address for CPU3 starting 0x103xxxxx. I tried the process above with that and it failed to write the 0x1030000 flash space for CPU 3 in step 4. Change back to original and now blinky works and even an adaptation for our own dual core works too. Really curious to what might have happened here? Also been looking for a memory map which details the default mapping for the SRAM/FLASH but cannot find anything. Does something exist?

Almost like some issue with the board that needed writing or resetting?

  

  • Simon,

    I actually have it working now with this process. I changed the cmd files for both CPUS to have all flash address for CPU3 starting 0x103xxxxx. I tried the process above with that and it failed to write the 0x1030000 flash space for CPU 3 in step 4.

    I'm not sure what you mean by this, but code start + CERT have fixed location at start of FLASH.

    Change back to original and now blinky works and even an adaptation for our own dual core works too.

    Did you POR in between runs? Because that would also work in lieu of XRSN since it's a device level reset.

    Also been looking for a memory map which details the default mapping for the SRAM/FLASH but cannot find anything. Does something exist?

    Could you elaborate what you mean? We have the memory map in device data sheet of the RAM/FLASH addresses. We also have the FLASH mapping based on BANKMODE in datasheet and TRM. Note that CPU2 does not have access to FLASH.

    Almost like some issue with the board that needed writing or resetting?

    This does not seem like a board issue beyond related to the reset.

    Best Regards,

    Aishwarya

  • Thank you for your response, I cannot remember if I did the POR. All I can say is that the process used to fail and now the same sequence works. I do not understand why.

    In terms of the memory map I am looking for I would like to understand where each processor sees the various SRAM and FLASH sections so that I can sort out some specific sections to share data. I have this working now between CPU1 and CPU3 in SRAM, sharing a section of CDA0. However the FLASH area for CPU3 is defined at address 0x10400000, which appears to be after the main 4MB of program/data flash, as the CPU1 flash starts at 0x10000000. I basically tried to move CPU3 flash area to 0x10300000 and it did not work, but I do not understand why?

    It seems that the ACCESIBLE SRAM sections start at 0x200E0000 and FLASH at 0x10000000, is that correct, and where might I find a full map? 

  • Simon,

    I separated the threads as this question is a bit different than what we originally were discussing. Thread linked here: F29H850TU: Multicore debugging - C2000 microcontrollers forum.

    I cannot think of something else HW setup wise that could be the reason for the fix. If you think of anything else, let me know.

    In terms of the memory map I am looking for I would like to understand where each processor sees the various SRAM and FLASH sections so that I can sort out some specific sections to share data. I have this working now between CPU1 and CPU3 in SRAM, sharing a section of CDA0. However the FLASH area for CPU3 is defined at address 0x10400000, which appears to be after the main 4MB of program/data flash, as the CPU1 flash starts at 0x10000000. I basically tried to move CPU3 flash area to 0x10300000 and it did not work, but I do not understand why?

    It seems that the ACCESIBLE SRAM sections start at 0x200E0000 and FLASH at 0x10000000, is that correct, and where might I find a full map? 

    SRAM and FLASH is memory mapped with a start/end address just like any other peripheral. Whether CPU1 or CPU2 access SRAM, they'd be using the same address. Assuming this is your understanding as well. For example, both LPA1 and CPA0 are accessible by all three CPUs. However, LPAx is optimized for CPU1 and CPU2 accesses while CPAx is optimized for CPU1 and CPU3 accesses. Same concept for LDAx and CDAx. 

      (snippet of Memory Map section in datasheet)

    If you look at any FLASH build example, you will see the CPU1 CERT @ 0x10000000, CPU1 codestart  @ 0x10001000, CPU3 CERT @0x10400000, CPU3 codestart  @0x10401000. Similar to CPU1, there is a fixed CPU3 codestart and CERT location.

    To reprogram the flash after flashing a non-valid codestart program, you can change boot mode to 00 from 11 (flash boot), do CPU reset or Power cycle, connect back, and flash valid code start program.

    Best Regards,

    Aishwarya