• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 299 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.

MSPM0G1107: Accessing NvMem via the dataflash

Edward Devlin
Prodigy 25 points

Part Number: MSPM0G1107
Other Parts Discussed in Thread: MSPM0G3507,

Tool/software:

Looking for my knight in shining armor aka Sir Dylan OBrien.

Keep hard faulting when using the TI dataflash library calls. Specifically, I get partially through the erase "clear" function, but before returning the status back to the top level function call, we hardfault to an invalid address or something.

Couldn't find an example for the 1107, but found one for the 3507 (flashctl_multiple_size_read_verify_LP_MSPM0G3507_nortos_gcc), and got it working in e2e.

However, bc of all the auto generate code, it's hard to transplant the working example into our build environment. Would love to hop on a call and do a show and tell.

  • 0
    TI__Genius 16050 points

    Hello Edward,

    Could you paste the function call here so I know which one you are using exactly, as well as the relevant parameters?

    As for the example code, you can use the example for G3507, then inside of the .syscfg file, you can click on the device view (shown in section 4.6 on this page - section 4.8 shows switching devices as well), and use the "switch" button to change the device to G1107. It may throw some warnings about pin configurations but for the flashctl examples this should be no problem. The flash memory map for the MSPM0G3507 will be the same as the MSPM0G1107 so you should also be able to execute the same flash reads and writes on either device. 

  • 0 in reply to Dylan OBrien
    Prodigy 25 points

    Using the same linker from the ccs example - flashctl_multiple_size_read_verify_LP_MSPM0G3507_nortos_gcc

    Rebuilt the G3507 example using the G1107 target like you suggested. This is the function that causes the hardfault

    Here is the exception thrown - seems to be executing from RAM bc of the 0x2020_0000 address, right?

    The difference is instead of the auto generated SYSCFG_DL_init() function, we use our own called DeviceDriver_AppHardwareInit() seen here - which effectively does the same stuff (I think?)

  • 0 in reply to Edward Devlin
    TI__Genius 16050 points

    You are correct that the function is executing from RAM, and the exception originating from 0x20200XXX indicates that it is coming from the ECC unchecked region of SRAM, which would be expected here.

    Also can confirm for your third image yes the function calls you are using are just our provided driverlib functions and they look like they're being used fine in this scenario.

    So back to the first image to clarify - when you run the provided example on G1107, you also get a hard fault? Or are you just saying that the highlighted function is what gives you the hard fault in your original application?

    For any case - it is important to know the address that you are passing (the second operand) and the size of the space you are erasing (the third operand). Could you let me know what these are for your example as well? This may reveal the issue.

    Additionally, when you experience the hard fault could you also copy-paste the contents of the xPSR registers here?