• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 898 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.

CCS/MSP432P401R: "Flash Programmer: Reading HW revision failed." & "No source available for 0x0"

Sean Howson
Prodigy 180 points

Part Number: MSP432P401R

Tool/software: Code Composer Studio

Hi

I''m using the MSP432P401R red launchpad, Windows 10, CCS (Latest version) and have already spent too long trying to solve this. I made the silly mistake yesterday of getting carried away and changing a huge amount of code in one hit without fully verifying each step.

Most of what i've changed related to the way the chip loads data in from various areas of it's flash memory upon start up which until now it has done without issue. 

I've had an error while starting debug as follows:

CORTEX_M4_0: Flash Programmer: Reading HW revision failed.
CORTEX_M4_0: Your XMS432P401R material is no longer supported. We recommend you moving to production-quality MSP432P401R/M silicon by ordering samples at www.ti.com/product/MSP432P401R.
CORTEX_M4_0: File Loader: Memory write failed: Unknown error
CORTEX_M4_0: GEL: File: C:\Users\Sean Howson\Documents\18 - Backup Archive Files\Workspace 2\MODBUS Adapter\Debug\MODBUS Adapter.out: Load failed.

previously this had happened once, a couple of weeks ago. A factory reset sorted the issue but now it is occuring roughly every other time i launch the debug. I haven't touched the TLV data or anything that might provide the debugger with an indication of the hardware i'm using. I've tried using two brand new boards and they've both produced the same error (both new boards updated their debug chips first).

The factory reset still temporarily solves the issue but i'm wasting too much time doing it and need to get to the bottom of the issue.

secondly i'm also having issues with the "source not found for 0xXXXX" with varying intensity. Sometimes the chip seems to find no source at all, other times it's fine. I did remove all of the debug symbols last week to reduce the size of the output file but i have since put them all back in (I only removed them from the release version anyway).

I had seem something on a forum suggesting it can be down to not properly configuring wait states for flash reading. I have since done this and tried various combinations of wait states with little success.

Additionally i've noticed, usually when i compile while already in a debug session CCS automatically loads the new code and resets the chip. It's now stopped doing this?

All I have done is alter code, yet many of these problems seem to be stemming from CCS?

I've tried switching workspace.

Tried endless resets and factory resets etc.

Tried loading the code in uniflash.

Any pointers or advice would help. Wasting a lot of time on these issues.

Sean

  • 0
    TI__Guru 53525 points
    Sean,
    Sorry that you are going through those frustrating restarts. I am not aware of a quick fix, but that is troubling that it is consistent across multiple devices.

    Can you confirm that you are not using XMS silicon? Does the actual chip on the launchpad say 'XMS' or 'MSP432'?

    You mention that you are moving a lot of data at startup - is this the c_init function? Are you using the startup_msp432p401r_ccs.c and system_msp432p401r.c files in your project. The Reset_handler calls SystemInit(), which handles the watchdog, before calling _c_init00.

    What frequencies, Vcore, and flash wait state settings are you using in your application?

    If you go 'back' to a simple example do these issues resolve?

    Regards,
    Chris
  • 0 in reply to Chris Sterzik
    Prodigy 180 points
    Hi Chris,
    Thanks for the reply,

    Yep i'm definitely using a chip labelled as MSP432 silicon, the issue seems to have somewhat subsided for now after a serious clean up and commenting out half the code & slowly re-introducing each segment. I still can't quite isolate the issue though. I notice the chip continually enters the "startup - infinite while loop" upon the first run after restarting the debug session, it's actually done this for a while & i've a feeling it may be something to do with the way i've set up the clocks/the order in which i've configured the clock setup etc.

    I'm not actually using any of the driverlib functions i tend to do everything at register level, just a preference. So i'm not using the init function. But i do have both of the files you reference, included.
    can you just elaborate a little on what you meant by
    "The Reset_handler calls SystemInit(), which handles the watchdog, before calling _c_init00. "?

    I'm running the DC0 at 48MHz, running in active mode Vcore 1, (DCDC). I have the flash wait states set to 1 as per the MSP432 technical reference. I think this is correct?

    As i kind of mentioned earlier, going back as step does somewhat clear up the issues, but i think there is still some underlying problem that was brought out by wednesdays overhall.
    Worst part is i'm not entirely sure what fixed it all yesterday! I was having to get on with some other bits as well which made it tricky to concentrate properly.

    Thanks for your help!

    By the way, if my peripherals are only operating at a max of 24Mhz, i notice when i introduce the clock cycles breakpoint, it indicates the chip is running at 24mhz, are there any aspects of the chip still running at 48, or is the chip slowed down based on peripherals?
  • 0 in reply to Sean Howson
    TI__Guru 53525 points
    The comment about the reset_handler is just to make sure that you are handling the watch dog. It is actually handled in the supplied system file which is called in the startup file. If you were not using these files, then I just wanted to make sure the issue was not some marginal timing issue where the WDT would time out before you actually entered your main code and handled the watch dog. You mentioned the loading of data at startup and concerned that somehow the initialization of variables was taking longer than the watchdog timeout.

    Your setup of the MCLK, vcore, and flash wait-states is correct.

    To your last point, I do not believe that the MCLK is changed based upon the peripherals. However, there is requirement on the peripheral access timing, please refer to table 5.25.2 in the datasheet.

    Regards,
    Chris

**Attention** This is a public forum