IWR6843AOPEVM: Abnormal after load firmware

Hello,

Are you using CCS Debug and trying to load your own custom binaries (we are unsure what you mean by normal firmware load)? Or are you using a release binary and operating the device in functional mode? What are you trying to do on a higher level? 

Regards,

Luke

We combined mss and dss build file to a .bin file, and use UniFlash to flashing the EVM in flashing mode.  I'm sure all the switch are in correct position.

I also tried using CCS . It failed when click "Test Connection" in "Target Configurations". Here is the log

[Start: Texas Instruments XDS110 USB Debug Probe_0]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

C:\Users\ADMINI~1\AppData\Local\TEXASI~1\
    CCS\ccs1200\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100/110/510 class product.
This utility will load the adapter 'jioxds110.dll'.
The library build date was 'Sep 20 2022'.
The library build time was '12:28:44'.
The library package version is '9.9.0.00040'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the XDS110 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for XDS110 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-233' (0xffffff17).
The title is 'SC_ERR_PATH_BROKEN'.

The explanation is:
The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
An attempt to scan the JTAG scan-path has failed.
The target's JTAG scan-path appears to be broken
with a stuck-at-ones or stuck-at-zero fault.

[End: Texas Instruments XDS110 USB Debug Probe_0]

Also failed if I click debug in CCS directly

Error connecting to the target:
(Error -2131 @ 0x0)
Unable to access device register. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
(Emulation package 9.9.0.00040)

Hi,

First, we want to make sure that you are actually flashing the device correctly. When using UniFlash with your custom binary you are building, are you seeing a success message in the terminal? And are you resetting the device after flashing and changing the switches?

Secondly, I would like to point you to the CCS Debug Mode documentation. Double check that you are following all of the correct procedures in the guide. Find that guide here: https://dev.ti.com/tirex/explore/node?a=1AslXXD__1.00.00.26&node=A__AKZl2I1OiS5ssBNGpidsCQ__radar_toolbox__1AslXXD__1.00.00.26

Hi Luke,

1. Yes, the last flashing was finished successfully with a message, and then I changed the switch on MMWAVEICBOOST to functional mode an push the reset button. The procedure has been done more than 50 times which is familiar to me.

2. I know the debug step described in that page, but the debug session run into abort function almost every time, which I can't figure out the reason. However, I can't flashing the debug firmware now. 

Hi

Were you able to flash the device with the debug firmware without problems in the past? What version of CCS and what version of SDK are you using? If you are following all the steps exactly and now something is going wrong, maybe the device or cable has become damaged. Or maybe you are simply missing a small step, which can always happen.

Getting the device successfully flashed with the debug firmware is a prerequisite for running your custom binary, so we need to solve that problem first. 

With the information you've provided me, I can't help beyond pointing you to the CCS Debug Mode guide I linked prior.

 Regards,

Luke

No, an error in the muxing or GPIO writing would not cause harm to the EVM, do not worry there.

I am glad you were able to find and correct your bug! If I am misunderstanding, and you have further questions relevant to this thread, feel free to ask. If you have another set of questions, open a new thread. 

Regards,

Luke

No, you misunderstood me. The program ran successfully on our self-designed board, not EVM. The EVM still cannot be flashed.

You are using the AOP + MMWAVEICBOOST correct? Can you try following the out of the box guide from the start and see if you can flash with one of our prebuilt binaries? 

https://dev.ti.com/tirex/explore/node?a=1AslXXD__1.00.00.26&node=A__ADFsv62CVEotGtkwF2Zxlg__radar_toolbox__1AslXXD__1.00.00.26

We need to determine first if you can flash with any program at all. If so, try following with the "Developer's Guide" part. If you can flash these binaries, then we know your switch settings are correct and your board is okay.

Regards,

Luke

Yes,  using the AOP + MMWAVEICBOOST. I tried what you say, but still failed. The core problem is, the EVM borad does not answer the break signal  from serial port, which makes the flashing can't work. I think the board may be damaged with some reason, for example, a block with the flash chip.

That is good! Thanks.