IWR1843BOOST: IWR1843BOOST

Here are the switch settings I have...

IWR1843BOOST...

SOP mode (debug/development mode).
SOP0: Off
SOP1: On
SOP2: On

S2:  SPI

On the ADC1000...

LVDS_MODE_SEL: 

16BIT_ON
14BIT_OFF
12BIT_OFF

SW2...

LVDS_CAPT:  OFF
SD_STORE:   OFF
1243_MODE:  OFF
RAW_MODE:  OFF
HW_CONFIG: ON
USER_SW1: OFF
USER_SW2: OFF
USER_SW3: OFF

Note: I did flash "mmwave_sdk_03_06_02_00-LTS\packages\ti\utils\ccsdebug\xwr18xx_ccsdebug.bin" which is something I believe is needed to utilize debug/development mode in order to load the rf_eval_firmware bss and mss files.  Should I be flashing something different?

Hello,

rf_eval_firmware bss and mss files would overwrite any .bin flashed to it prior. So although not used, having flashed xwr18xx_ccsdebug.bin should not have affected anything in theory. That said please check the photos for switches in this user guide. They are wrong based on what you have written

https://dev.ti.com/tirex/explore/node?a=1AslXXD__2.20.00.05&node=A__AGTrhNYW8jE6cMxbovlfaA__radar_toolbox__1AslXXD__2.20.00.05

Best Regards,

Pedrhom

Per the DCA1000 mmWave Studio User Guide:  "Make sure your device’s SOP mode is in “Development” mode, which is where SOP0 and SOP1 are ON and SOP2 is OFF with regards to the mmWave sensor."  However, whenever I configure for this mode the NERR light illuminates (see "Debug Fails" picture) and I am not able to connect to the device via CCS.

.

When I configure as follows: SOP0: OFF, SOP1: ON, SOP2: ON, the NERR light is off (see "Debug Good" picture) and I am able to connect via CCS and load and step through an application.

I have seen this behavior even before adding the DCA1000 module to the 1843 EVM.

Thank you,

Ron 

Hello Ron,

Why are you trying to connect to the device via CCS when in Development/DCA1000 mode? When the radar sensor is set like this, the DCA1000 interfacing is what will be working. Ignoring the LED, are you able to connect in mmWaveStudio like this?

Best Regards,

Pedrhom

I am not trying to connect to the device via CCS when attempting to use the mmWaveStudio.  I am just trying to point out that there might be an issue with how the dip switch settings are documented.  The mmWaveStudio and CCS both seem to want development mode (which I assume is the same as debug mode) to have SP2: Off, SP1: On, SP0: On.  However, I have not been able to get debug to work with CCS with those dip switch settings.  The only way that I can get CCS to work with this device is with the dip switch settings SP2: On, SP1: On, SP0.  Wonder if this is an issue with Rev C of the board (which has dipswitches instead of jumpers)?

Noticed a typo in my message above. The second to the last sentence should read: The only way that I can get CCS to work with this device is with the dip switch settings SP2: On, SP1: On, SP0: Off.

Hello,

This makes sense, and I see where the problem is. The naming terminology here is definitely confusing since we are using "debug" twice but meaning two different things. CCS only needs the device in either functional or flashing mode to run CCS Debug for application code debug. Debug hardware configuration mode is for raw data capture and other front-end RF, chip level debug, aka DCA1000 + mmWaveStudio.

Best Regards,

Pedrhom

Hi Pedrhom,
Thank you for the feedback. I am getting a clearly picture now of how this works.
A related question to further clarity... 
For flashing the onboard QPSI device with the CCSDebug.bin, I expect the XDS110 emulator uses just the JTAG interface for that.  Then when the device is rebooted in functional mode, would it be correct that the CSSDebug.bin application communicates with CCS over the UART, not JTAG?   Or does CSS continue to use both the UART and JTAG for debug operations?  Or is the UART just for the initial download?

Thank you again,

Ron

Hello Ron,

When you are flashing using Uniflash or any similar tool to flash a .bin, you boot over UART and that is how the binary is flashed. When you have a .out, and load it in CCS for debug, you are loading the memory via JTAG. You have to be in flashing mode to flash .bin over UART, whether this be application code or the CCSDebug image that allows JTAG (C:\ti\mmwave_sdk_03_06_00_00-LTS\packages\ti\utils\ccsdebug\xwr18xx_ccsdebug.bin). Afterwards in functional mode, you either automatically run your application if you flashed a demo or manually load in the .out over JTAG to run if you flashed CCSDebug.

Best Regards,

Pedrhom

So, if I load my application via CCSDebug (which uses JTAG), then my application is free to use the UART when it starts running?

One thing I am still confused about is regarding this statement: "When you are flashing using Uniflash or any similar tool to flash a .bin, you boot over UART and that is how the binary is flashed".  I would think that for the target device to utilize the UART, it would already need an executable running.  This seems to be a chicken-and-egg problem.  If we have a corrupted flash, how would Uniflash communicated with the device?  My sense is that Uniflash would only use JTAG for programming the flash device, not the UART?

Perhaps we might need to clarify.  My understanding is that the XDS110 emulator instantiates two serial interfaces via the USB connection: 

• "Class Application/User UART"
• "Class Auxiliary Data Port"

Are these just pass through to IWR1843 device?

Thanks, Pedrhom, the pieces are starting to come together...

I assuming you are referencing section "4.5 Boot" of the IWR Family TRM? Ok, starting to understand better, I think. But still unclear on some things. The background here is that our production board is going to be very tight on real-estate, so we are not going to be able to have the standard headers for connecting a real XDS110 debug probe. Our hardware guys are thinking we should be able to program the flash device and debug the application solely using the JTAG interface. However, it sounds like Uniflash must have the Application UART connected to program the flash? (To confirm, the boot ROM is actually flashing the device. Uniflash is just communicating with the boot ROM via the UART interface. Correct?)

Related, I see inconsistencies in documentation that is confusing. Section 4.5 of the IWR Family TRM indicates there are only two SOP configurations that are of use and that the others "result in unknown device behavior". However, the xWRI1843BOOST Users Guide indicates three SOP configurations. And even further, the xWRI1843BOOST schematic indicates five SOP configurations. Possibly to clarify what is what regarding use of the three SOP switches?

What is the CCSDebug.bin doing that the boot ROM is not doing? Why sense is that the boot ROM is used for simple boot and flashing support, whereas CCSDebug additionally initializes the various subsystems into a usable state. CCSDebug then also provides support for downloading MSS and DSS applications to RAM and launching them? And once the applications are launched, the UARTS are no longer used for booting / debugging? After that, all debugging takes place via JTAG?

If all of that is making sense, then in a target system where the applications is booted via flash, I can still debug via JTAG (without further need for the UART)?  However, I cannot flash the QSPI device via JTAG alone?

Hi Pedrhom,

Thank you for the clarification of the dip-switching settings.  All good there now.

I am confused by "After a one time flashing of the CCSDebug.bin over UART, you can flash the QSPI device via JTAG alone as many times as you'd like.".  I would think that if I flashed the QSPI device via JTAG alone, then that would have replaced the CSSDebug.bin with whatever I had replaced it with.  This seems to indicate that CCSDebug is not needed to use JTAG alone? 

Also, I haven't found anything solid as to how to use Uniflash (version 9.1) or CCS (version 20.1) with JTAG only.  Uniflash seems to require a COM port.  For CCS, the mmwave sdk user's guide states "Debug/JTAG capability is available via the same XDS110 micro-USB port/cable on the EVM. TI Code composer studio would be required for accessing the debug capability of the device. Refer to the release notes for TI code composer studio and emulation pack version that would be needed.", but I haven't been able to figure that out.

Thank you again... making progress here. I very much appreciate your patience with this newbie to these devices and tools.

Ron

Hey Ron,

We have a JTAG Flasher tool that allows the flashing of a MetaImage .bin via JTAG without any UART interface. The user guide is on the Radar Toolbox in the TI Developer Zone.

https://dev.ti.com/tirex/explore/node?node=A__AWIoiRGl9nAtaaUSJLDghw__radar_toolbox__1AslXXD__LATEST

Best Regards,

Pedrhom