RTOS/TDA2PXEVM: Debugging an exception

TG2718

Part Number: TDA2PXEVM
Other Parts Discussed in Thread: AWR1243

Tool/software: TI-RTOS

I'm modifying Processor SDK Vision/Radar code (version 3.3.0.0) to support a custom board utilizing AR1243 chips interfaced to a TDA2PXEVM. Some of the examples assume a TDA3x, which only supports 3 UARTs. I modified BSP_AR12XX_NUM_UART_INST and added corresponding entries to bspdrv_ar12xxUartCfgPriv.c gUartModuleAddrList[] and gUartDriverNames[], which is static memory.

Now the code crashes everytime Bsp_ar12xxUartInit() runs, right when I step into the second for loop. This may be due to nearly full memory that blows up when Error_Block eb is defined on the stack. However, I tried adding the equivalent stack allocation within the first for loop to test if it would crash earlier, and it did not.

ROV Classic decodes the exception as:

The exception call stack indicates that the error occurs at line 187, not approximately 164 as seen when stepping line-by-line in the debugger.

I wondered if code optimization was causing a discrepancy about which line was being executed. The build was in debug mode, and I added the following to build_config.mk to make sure this was explicit but did not see any change:
PROFILE_ipu1_0 = debug
PROFILE_ipu1_1 = debug

I modified Processor_SDK_Vision_CCS/vision_sdk/links_fw/src/rtos/bios_app_common/tda2px/cfg/BIOS_common.cfg with the following lines, but did not observe any initialized values with the memory browser and was not notified of any memory problems:

Task.initStackFlag = true;

Task.checkStackFlag = true;

Hwi.initStackFlag = true;

Hwi.checkStackFlag = true;

BIOS.heapTrackEnabled = true;

I modified the stack size in Ipu1_0.cfg from 0x4000 to 0x6000, but this had no effect.

I watched TI's tutorial Debugging Common Application Issues with TI-RTOS but was still unable to resolve these issues (training.ti.com/debugging-common-application-issues-ti-rtos).

Questions:
1. How can the debugger and exception call stack disagree about what line was executed? If it is optimization related, how can I disable that and why was debug mode insufficient?

2. What do I need to change to allocate more memory in the appropriate place? I assume it is the system stack or heap that is a problem, not task stack or heap?

Thanks!

over 5 years ago

0 Stanley Liu over 5 years ago

TI__Guru 50045 points

Hi,
From the decoded exception field, it clearly indicates the exception was caused by accessing 0x4806800C.
This is UART6_LCR register. The reason for the exception is because the UART6 module is not enabled by default.
UART1 ~ 3 are enabled by default. For the other UARTs, you have to enable the module before calling Bsp_ar12xxUartInit().

Please refer to PROCESSOR_SDK_VISION_XX_XX_XX/vision_sdk/apps/src/rtos/modules/ultrasonic_capture/ultrasonicCaptureLink_hw.c.
It provides an example how UART10 is enabled.

Regards,
Stanley

0 TG2718 over 5 years ago in reply to Stanley Liu

Intellectual 1000 points

Thanks - that was very helpful. I followed the example in st_uartPlatform.c: st_uartEnableUartInstance(). It definitely gets further, although I was not able to erase the firmware on the AR1243 yet - it times out waiting for the UART break response.

0 Stanley Liu over 5 years ago in reply to TG2718

TI__Guru 50045 points

How do you connect the AWR1243 connected to TDA2P EVM?
Is it connected over FPD-LINK thru UB960 on Fusion Board or directly to CSI2 interface on TDA2P?
If directly, do you have GPIOs set up for Reset, SOPs, and Host IRQ from AWR1243?
This is required to boot AWR1243 before you can talk to AWR1243 and flash firmware.
You can refer to the Radar SDK user guide to see how AWR1243 is connected to TDA3 EVM.

0 TG2718 over 5 years ago in reply to Stanley Liu

Intellectual 1000 points

It is directly connected via CSI-2 on a custom board that plugs into the TDA2Px. I believe all the GPIOs are setup properly. I can program firmware via SPI, but flashing via the UART does not work yet.

0 Stanley Liu over 5 years ago in reply to TG2718

TI__Guru 50045 points

Do you know which AWR1243 ES revision is on the customer board?
You don't have to flash firmware for ES3.0.

0 TG2718 over 5 years ago in reply to Stanley Liu

Intellectual 1000 points

We have ES2.0 chips.

0 Stanley Liu over 5 years ago in reply to TG2718

TI__Guru 50045 points

Please double check the pin mux for the UART pin used for flashing.

On EVM, you also need to check schematics to see if there is any board mux you need to configure so it routes the right pins to the interface.

0 TG2718 over 5 years ago in reply to Stanley Liu

Intellectual 1000 points

I confirmed that the UART TX/RX pins appear to have the correct pin mux settings and that those signals do not pass through any other muxes on the EVM board or our custom RF board.