• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 84 subscribers
  • Views 237 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

TMS320F28P659DK-Q1: Dx memory allocation to CPU 2

TMS320F28P659DK-Q1: Confirmation of Reset Values for MCUCNF0 & MCUCNF1

Chen-Chih Liu
Intellectual 340 points

Part Number: TMS320F28P659DK-Q1

Tool/software:

Dear Experts,

I would like to confirm the reset (init) values for MCUCNF0 and MCUCNF1. Based on my observation, after boot-up and before writing to these registers, MCUCNF0 is 0x01 and MCUCNF1 is 0x00.

I also have another question: if I configure MCUCNF1 to 0x3C (setting D2 - D5 for CPU2), will MCUCNF0 revert to 0x01 and MCUCNF1 revert to 0x00 after a Watchdog reset? The TRM mentions that the reset value is 'X', which confuses me.

Thank you for your support.

Best regards,

CC Liu

  • +1
    TI__Mastermind 44190 points

    Hi CC,

    The value after power cycling MCUCNF0 will be '1' for device variants that are dual core (e.g. F28P65xDxx) and '0' for device variants that are single core (e.g. F28P65xSxx).  For device variants that are dual core, MCUCNF0 can be cleared to 0 however, MCUCNF0 cannot be set to '1' for single core device variants.  Upon power up, MCUCNF1 will have default value of '0', meaning D2 to D5 memories are allocated to CPU1.  Once application programs this register to reallocate them to CPU2, for instance by writing '3C' to this location, the value remains there even after a RESET.  This is also true for MCUCNF0.  RESET will not change the value that was written to this register for the case where dual core device F28P65xDxx register MCUCNF0 is cleared to '0' to emulate a single core device.

    Regards,

    Joseph

  • 0 in reply to Joseph Casuga
    Intellectual 340 points

    Hi Joseph,

    Thank you for your reply.

    I have a follow-up question:
    Is it safe to call the function SysCtl_allocateDxRAM() to re-allocate all Dx RAM to CPU1 at the beginning of main(), before any system initialization?

    My concern is that our Bootloader runs only on CPU1, while the Application uses both CPU1 and CPU2 (with the CPU1 application allocating some Dx RAM to CPU2). When the system resets (triggered by WatchDog reset) from the Application back to the Bootloader, the Dx RAM previously allocated to CPU2 may remain unchanged, which could cause problems for the Bootloader.

    Thank you and best regards,

    CC Liu

  • +1 in reply to Chen-Chih Liu
    TI__Mastermind 44190 points

    Hi CC,

    That should be OK as long as the reset caused by WD would reallocate the all Dx RAM to CPU1 then assign some for Dx RAM to CPU2 at a later time.  It seems that it is the Dx RAM allocation order in your application that you need to follow.

    Regards,

    Joseph