• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 15 subscribers
  • Views 1081 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

SMJ320F2812: During testing phase of SMJ320F2812 based card, controller malfunction is noticed after one flash write attempt

Rahul Ramachandran
Prodigy 730 points
Part Number: SMJ320F2812

During testing phase of SMJ320F2812 based card, controller malfunction is noticed after one flash write attempt. (Previous to that, several time flashed and working). Our code is written to flash and after booting, flash contents is loaded to RAM, from where it is thereafter executed. It looks like flash programming is successful, but after power cycling, the flash contents are not getting copied to RAM.

Kindly help in sorting the issue.

MC pin is set to 0 and GPIOF4 is pulled up to Boot from flash address 0x3F 7FF6. Is there any way to verify whether it is really booting from flash.

  • 0
    TI__Guru 62930 points
    Rahul,
    I am going to move this to the C2000 team to for support (primarily due to fact that I will be on vacation until Aug 31)
    Please provide more details to help understand. They may have some additional question.
    Is this a one-off issue only affecting 1 device, or all boards tested? The later would indicate a systematic issue and likely code related. The former may indicate damage to device, board, or improper flashing.
    The code development environment should be able to view memory contents. This inspection should show if flash was actually programmed.
    Regards,
    Wade
  • 0 in reply to Wade Vonbergen
    TI__Guru* 93825 points

    Rahul,

    If this operation has been done many times before and worked properly, it is unlikely to be a tool-chain or board issue.

    1. Is it possible that some other component on customer's board is causing the issue?
    2. Did customer use CCS to verify (a) The flash was correctly programmed? (b) Code was correctly copied to RAM as intended?
    3. Customer could add toggle of a GPIO pin before code is copied to RAM and after code is copied to RAM , as a diagnostic aid.
  • 0 in reply to Hareesh Janakiraman
    TI__Prodigy 730 points

    Thanks Hareesh

    We checked flash and RAM content using CCS after booting. Flash contents are updated, whereas RAM locations are filled with junk data.

    As we are able to directly load from PC to RAM and debug, it looks like issue is with booting. As booting is controlled only by MCU and GPIOF4 pins (both of which we have verified), card issue is not suspected.

    So once again, Is there any way to verify whether it is really booting from flash?

  • 0 in reply to Rahul Ramachandran
    TI__Guru* 93825 points
    Rahul,
    It is critical we confirm the flash image is accurate. Did the customer dump the flash image as a hex file and compare it with the source COFF file (after converting it into HEX)? If so, please have the customer do this simple test:

    Step 1: Replace their application code with a simple GPIO toggling program and program it into flash. Let this code run out of flash itself (no copying into RAM etc). This would verify if booting to flash is working correctly.

    Step 2: If step 1 is successful, now modify the code so that it gets copied into RAM and executed from there. See if this code correctly get copied into RAM and executed.

    We need to simplify the problem/debug, in order to zero in on the culprit.