IWR1642: XDS-200 Cannot connect to IWR1642

Hi Raymond,

I will need to ask my team about this. I am not very familiar with XDS-200. Please allow a few days for a response.


Cheers,
Akash

Any news on this?  If I have to, I can do a kludge to the XDS-110 on the Evaluation module, but it is nicer to have clean cables!

Thanks for checking.

Ray

Hi Raymond,

I have asked our CCS team to look into this query, please allow a few days for a response.


Cheers,
Akash

Here is the error I get:
Cortex_R4_0: Trouble Writing Memory Block at 0x0 on Page 0 of Length 0x3c: (Error -1065 @ 0x0) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.1.0.00005)
Cortex_R4_0: File Loader: Verification failed: Target failed to write 0x00000000

I did a search on "Error -1065" and it did not come up.

In addition to passing the "Verify Connection" task in the Project setup dialog, I am able to type characters and see them echoed back on the console, so we know the base unit is wired correctly and at least minimally functional.

It is not clear if the GEL file is attempting to load the program into internal RAM or into the QSPI flash memory.

Thanks for the help so far!!

Hi,

Please apologize for the delay; I missed your last reply.

The error message is typical of the scenario you mentioned: the Debug Probe cannot write to the specific memory address 0x0, which in the case of the IWR1642 is, in fact, mapped to ROM.

This is usually caused by an invalid allocation performed when the application is linked - thus, an issue with the memory allocated by the linker CMD file or SYSBIOS/TI-RTOS components of the project.

To be absolutely sure of the status of the memory on the device, check the "Data Verification Errors" page below, more specifically the section "Available Target Memory".
software-dl.ti.com/.../troubleshooting-data_verification_errors.html

The page above also mentions a few other tips to isolate the issue.

One or more internal GEL functions are called internally by the Debug Server engine, including during the program load. Thus an error coming from a GEL function does not necessarily indicate a problem with the well known GEL files that initialize the Device during Debugging.

Hope this helps,
Rafael

Rafael:

Many thanks. That has gotten me a bit further. I made a change to r4f_linker.cmd which was copied from the C:\ti\mmwave_sdk_01_01_00_02\packages\ti\platform\xwr16xx directory when we were using a version 1 silicon reference design. The modifications I made remove the error but I still cannot load and debug.

Here is the original:

/* Memory Map */
MEMORY{
VECTORS (X) : origin=0x00000000 length=0x00000100
PROG_RAM (RX) : origin=0x00000100 length=0x0003FF00
DATA_RAM (RW) : origin=0x08000000 length=0x00030000
L3_RAM (RW) : origin=0x51000000 length=0x000A0000
HS_RAM (RW) : origin=0x52080000 length=0x8000
}

and here is my modification:

/* Memory Map */
MEMORY{
VECTORS (X) : origin=0x00200000 length=0x00000100
PROG_RAM (RX) : origin=0x00200100 length=0x0003FF00
DATA_RAM (RW) : origin=0x08000000 length=0x00030000
L3_RAM (RW) : origin=0x51000000 length=0x000A0000
HS_RAM (RW) : origin=0x52080000 length=0x8000
}

The file from the Version 2 SDK adds more wrinkles!

I suspect we have an issue where an environment variable is not set correctly since the example seems to bring in the r4f linker command file from the TI install directory and we are clearly bringing in a local copy.

The good news is that changing the origin of the vector and program memory segments solves the load problem. However, the program loads and heads off without ever stopping at main() and only the red stop button is active.

I am curious why the linker command file in the SDK has an origin of 0x00000000 when it clearly should be 0x00200000?

The values for DATA_RAM, L3_RAM, and others all are as expected.

Rafael:
I still had some startup issues in my project file. Once I got those sorted, I am able to load and stop at main. I am also able to single step at least for a little way.

Still interested in why the r4f_linker.cmd has ROM addresses rather than RAM addresses.

Waiting on that answer before marking as answered.

Thanks.

Ray

Ray,

Thanks for sending the additional details; i agree with you that your second linker CMD file contains something that actually makes sense when loading code to the device: the TCM RAM-A starts at address 0x200000.

I couldn't really pinpoint the exact reason why the SDK linker CMD file would try to place the Interrupt Vector Table at address 0x0, unless the device has a configuration that overlays this internal Bootstrap ROM with an external RAM/Flash memory. 

With this in mind, I opened the device's Technical Reference Manual (SWRU522) and the same memory map table has an additional note:

 

Searching the document for "Eclipsing", I found the explanation:

Therefore, the device indeed has a mode that overlays the ROM bootstrap code and it seems to be executed at the end of this bootstrap. However, I lack the additional knowledge the device experts have about the whole boot process. 

Hope this helps,

Rafael

Ray,

In our modern world of devices with 32 or 64-bit addressing space and all the memory one could ask for, we naturally forget about these old techniques of "saving" or "increasing" the available memory - I myself was also completely surprised when I found this mechanism in these devices (I had an entire different answer already typed when I found this).

Thanks for the suggestions; the device team is also monitoring this thread and your message certainly reached them (I am part of the dev tools team, thus I don't influence the examples or the device documentation).

I will take a stab to try and find out what is different between the dev kit and a standalone board - maybe a bootstrap mode of sorts.

Regards,
Rafael

Rafael:

I just had a thought about why this works on the Launchpad but not on a freshly minted board.

The Launchpad is loaded at the factory with a working Radar system image which means the boot loader will find the image and then load it into the MSS and DSS as soon as power is supplied. The last thing it does is to turn on the eclipse mode for the MSS. That means when the JTAG debugger goes to attach, the Eclipse mode has already been triggered . Therefore, a load to 0x00000000 will work just fine.

Conversely, a virgin board such as what I have, has no serial flash image to load, so the bootloader stays active waiting to have a down load. That means that the ROM is occupying 0x00000000.

That scenario would exactly explain why I saw the error on load but not on the Launchpad!

If you can confirm with the experts in the Sensor group, we should add that to the instructions somewhere. Perhaps two or three "somewhere's". I would think the User Guide and the Technical Reference. Perhaps also a "Bringing Up Your First IWR/AWR Board" app note.

Ray