• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 644 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:

IWR1642: XDS-200 Cannot connect to IWR1642

IWR1642: XDS-200 Cannot Connect to IWR1642 -- an explanation

Raymond Mack
Expert 1575 points
Part Number: IWR1642
Other Parts Discussed in Thread: MMWAVE-SDK

The first step in trying to bring up our brand new boards from the factory was to build our code for the MSS and attempt to load and single step. CCS gave an error -1065 because it could not load the image starting at 0x00000000.

I am pretty sure I figured out why our code that is linked at 0x00000000 works on a Launchpad but not on our fresh from the factory boards. The Launchpads are loaded with code in serial flash at the factory, so they run through the bootloader and have a RAM image right after power is applied. The bootloader switches the part into ROM Eclipse mode once the factory code is loaded.  From my recollection of other ARM work, the Eclipse/Shadow feature is sticky across software and hardware resets, but not across power cycles. This means that the Launchpad has actual RAM at 0x00000000 almost immediately. Since our boards have never been loaded with a proper image, the bootloader sits in boot load mode and the ROM is still active at 0x00000000.  The workaround is to copy the linker command file from the SDK into the project and set the ORIGIN for the vector table and .text sections to 0x00200000 until the Flash program store has a proper image loaded.

The Eclipse mode is only documented in the Technical Reference Manual.

 I would recommend an application note covering “bringing up your first mmWave Sensor Board” that covers things like the stackups and other hardware issues as well as this “surprise” for connecting to the MSS with JTAG debug software.  I think y’all may have a start on such an app note.

Many thanks to Rafael for getting me to this   point!!

 

  • 0
    TI__Mastermind 30405 points
    Hi Raymond,

    Based on your original thread, I assume that you've resolved the problem, is that correct? Please allow me to understand the issue and discuss with our software team. I'll also check if the guidance you suggested already exists. I'll get back to you by Wednesday next week.

    Regards
    -Nitin
  • 0 in reply to Nitin Sakhuja
    TI__Mastermind 30405 points

    Hi Raymond,

    Looking at the TRM, it very clearly states that ROM eclipsing is performed by the device bootrom and the application view is always the post-eclipse view i.e. starting at address 0x0000_0000 which is what the SDK linker command file r4f_linker.cmd uses so I'm not able to see the discrepancy you're reporting.

    If you are developing your code on the IWR device, the R4F core will only see the post-eclipse view. From your original post, it appears that you used an alternate platform to develop the R4F application code, since you talked about your code working on the Launchpad. This is not the typical or recommended scenario. Typically, users will and should develop an application on the actual platform (please correct if my understanding is incorrect).

    Regards

    -Nitin

  • 0 in reply to Nitin Sakhuja
    Expert 1575 points

    Nitin:

    Please look at the boot sequence in SWRA563 Bootloader Flow.  Look at Figure 4. If there is no valid flash image (a virgin Flash device) and the part is in "Functional Mode", the Bootloader will take the "No" path and sit and wait for commands. The bootloader will never get to the ROM Eclipse step because it is waiting for a command. See the rectangle in the sequence: "Set up SPI. Generate a HostIRQ to indicate bootup completion and await commands."

    Please verify that is the case. If so, it means that until you load a valid image in external serial Flash (so it takes the "Yes" path), you will not be able to use the debugger with an image linked for 0x00000000 as the base.

    By the way Figure 4 is defective. It shows "SOP4" as "Functional Mode". Table 1 clearly says that "SOP1" is "Functional Mode". The only way it would be SOP4 is if y'all screwed up and made SOP2 as the LSB rather than SOP0 ( a very unlikely case).

    Ray

  • 0 in reply to Raymond Mack
    TI__Mastermind 30405 points

    Hi Ray,

    Thanks for the explanation. I need to check this with our design team to understand whether this is a valid scenario and the expectations from a factory/manufacturing perspective. I'll also check the SOP1 vs SOP4 item you noted. I'll get back to to you within this week.

    Regards

    -Nitin

  • 0 in reply to Nitin Sakhuja
    TI__Mastermind 30405 points

    Hi Ray,

    Thanks for your patience. Please find my responses as noted below:

    [Ray]: "Please look at the boot sequence in SWRA563 Bootloader Flow.  Look at Figure 4. If there is no valid flash image (a virgin Flash device) and the part is in "Functional Mode", the Bootloader will take the "No" path and sit and wait for commands. The bootloader will never get to the ROM Eclipse step because it is waiting for a command. See the rectangle in the sequence: "Set up SPI. Generate a HostIRQ to indicate bootup completion and await commands."

    [NS]: The part highlighted in red is not correct. In functional mode, If a JEDEC compliant flash is connected, the bootloader will get a valid SFDP response (as noted in section 2.1.1), and will move on with the Yes branch (Flash present). In this case the bootloader expects a valid image to be available in flash otherwise it falls into an error condition which is what happened on your board with a Virgin flash device. In other words, not having a Flash connected is different than having one connected but leaving it empty which is an invalid condition and causes the bootloader to fail.

    This is noted in the MMWAVE-SDK user guide as shown below and the SDK provides a valid image called ccsdebug.bin under C:\ti\mmwave_sdk_02_01_00_04\packages\ti\utils\ccsdebug. This image includes the RadarSS firmware and a very small MSS code (essentially some initialization and then a never ending while loop). The main purpose of this image is to keep the bootloader happy so that it eclipses the ROM at the end of successful execution. You can then connect the debugger and load your application without having to re-build it with different load address. 

    However, your feedback is very valuable and I'm checking with our team if this information is already included in an existing app note (other than the MMWAVE-SDK user guide), otherwise we'll identify the correct document to include this information so that it is highlighted in a better way.

    Please get back if you have more questions on this topic. 

    Regards

    -Nitin