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.

MSP430FR5994: Reserved Memory

Part Number: MSP430FR5994

Hi Team,

Reaching out to you as our customer wants to know the supposed value and purpose of the reserved memory of the MSP430FR5994. The memory address is given on section 9.15 of the datasheet.

Can you also tell us possible implications of overwriting this reserved memory? Would this lead to an error?


Thanks in advance!


Kind Regards,

Jejomar

  • Hi Jejomar,

    From figure 9-1 it looks like the JTAG password can extend into this region.  That said, because the memory is shown as reserved, there may be some undocumented constraints surrounding it's access.  Hope this helps.

    BR,
    Leo

  • Hi Jejomar,

    you refer to the reserved memory at 0x0000 - 0x0009 right? This area of the memory is ROM so you cannot overwrite it at all.
    At this region a hard coded bis  LPM4,SR is coded to have somewhere a fixed CPU instruction having the possibility to bring the device into a safe state.
    Depending on MPU settings you might trigger access right violations here.

    So finally recommendation is not to write at this memory area.

  • Hello Dietmar,

    i will paste part of a "Reading Code File" in which you can see that the data of the reserved memory has been overwritten. The data standing there is from the start of INFO memory at 0x1800. If the reserved memory really is ROM that wouldn`t be possible. If you have any idea how that could have happend if it is ROM please let me know, so we can make sure it doesn`t happen again to one of our devices.

    Reading Code File ...........................     done

    -- Code size = 0x2EF2 ( 12018 ) bytes

    Code from the file warnings report

    Addr 0002: 30 31 32 33 34 35 36 37

    Addr 000A: 38 39 41 42

    Addr 000E: 00 2C 01 D0 07 00 00 00

    Best regards 

    Nicolas Wödy

  • Nicolas

    so what are the absolute addresses of the data you provided?

    If I get it right it is as following (pls correct me if I'm wrong)

    @1802
    30 31 32 33 34 35 36 37
    @180A
    38 39 41 42
    @180E
    00 2C 01 D0 07 00 00 00

    This memory area is in Segment D of the info memory and does not belong to the reserved memory area you asked before. So please help to clarify what you really looking for?

  • Hello Dietmar,

    The address this file is referring to is 0x0002, but the data at 0x0002 is "duplicated" from INFO memory.

    Best Regards,

    Nicolas Wödy

  • Hi Nicolas,

    ok got it so you copy the data from 0x0002 to 0x1800. Indeed this is very strange. Do you have the capability to connect CCS or IAR with JTAG debug probe and open the memory window to read out the memory at 0x0000 to see what data are in.
    I wonder how the read and write was done maybe something was wrong with it.

    As said it is ROM and cannot be overwritten. I will have physical access to a FR5994 tomorrow and will double check.

  • Hello Dietmar,

    I am afraid that we aren`t able to flash anymore,  because the controller isn`t working properly.

    Best regards,

    Nicolas Wödy

  • Nicolas,

    do you have a device which is know to be good? At least it would explain why you read out such strange things.

    Is it possible to program a simple LPM4 bench with all GPIOs properly terminated to see that it consumes the expected current? This is always a quick check that the device is not very obvious damaged.

  • Dietmar,

    we have multiple working devices, but we don`t get the same reading on the working devices.

    The controller has allready been removed from the circuit board, because it didn´t work and the device had to be repaired.

    Best regards,

    Nicolas Wödy

  • Hi Nicholas,

    I mean this points to a damaged device as recommended put it into socket board program simple LPM4 test and check for EIPD (Electrical Induced Phyiscal Damage) by comparing the LPM4 vs. expected value. If confirmed I recommend to check the application for proper ESD handling or any over voltage/current conditions.


    Can you pls post the read out from a working device?

  • In a working device we have 0x32 0xd0 0xf0 0x00 0xff 0x3f 0xff 0x3f 0xff 0x3f as reserved memory.

    Could it be that the start pointer didnt´t point to 0x0000 but instead to 0x1800 and that is why we got that reading of the INFO memory data?

    Best regards,
    Nicolas Wödy 

  • This is the content I expect to get from these addresses! You can see the 0x3FFF which represents the jmp $ and the first addresses (0x0000  is missing) represents the hard code bis LPM4,SR.

    No idea why on the failing unit you get that garbage data but finally it is a looks like a counter value goes from 30 upwards. Do you have this kind of code or data somewhere in your code?

    One question: Why do you read this kind of data into info memory?

  • Its not a counter, this sequence is hardcoded to the start of INFO at the moment. Later it is supposed to work as a product code.

  • Hi,

    today I read the reserved memory on a FR5994 RevC and show below how it should look like. This memory area is ROM (read only) and cannot be written.

    So if you code reads data incorrectly from these addresses something is wrong with the device.
    As said please perform a simple LPM4 bench to check if it is drawing high current.

  • Hello Dietmar,

    it isn`t possible to flash a new firmware on the controller.

    Best regards,

    Nicolas Wödy

  • Hi Nicolas,

    this sounds like the part was obviously somehow damaged so further drilling into this from a memory or SW point of view makes absolutely no sense.
    Not sure how you handled the part or under what conditions it was operating.
    I would recommend to observe your product for additional units with similar behavior to see if this is something systematic or not. So far there is not a lot you can do here.

  • Hello Dietmar,

    the device came back from a customer, so I can`t tell you either at the moment.

    Still thanks for helping.

    Best regards, 

    Nicolas Wödy

  • Nicolas,

    thanks for the info even more worse not knowing the conditions. As said watch your production for similiar units and then come back to TI.

    Sending a single unit to TI will neither help you nor TI to understand it especially not knowing the fail conditions. So if you agree I would close this thread for now.

**Attention** This is a public forum