CC2340R5: CC2340R5/CC2340R2 on UART unexpected data being printing upon every Restart.

Hi Vignesh, 

Thank you for reaching out. 

When re-booting the device - I guess through a reset or similar - the GPIOs first lose power and the are configured to the value set by SysConfig in the table gpioPinConfigs[]. I believe this is what you observe here.
In order to confirm this behavior, I would recommend using a logic analyzer and consider changing the default pin configurations. 

I hope this will help,

Best regards,

Hi clement,

We have tried capturing TX line using DSO(Digital storage Oscilloscope) and we found after reset pin is becoming high then transmitting 0xFD / 0xFC then with x delay transmitting actual payload. For you reference attached image below.

For your input we have tried configuring serialIoCfgIndex == 0 we are getting 0xFC and serialIoCfgIndex == 1 getting 0xFD

But where as in serialIoCfgIndex == 2 we are not getting any additional bytes on UART.

We have tried one more by changing the pin configuration open drain with internal pull-up and hardware pull-up also still we are getting additional byte on UART.

Hardware Detail: 

1.CC2340R5 & CC2340R2 (4x4).

Software Details:

1.SDK Version : simplelink_lowpower_f3_sdk_8_10_01_02 (peripheral)

2.CCS version: CCS 12.7.1

Can you recommend us which serialIoCfgIndex to be used.

Kindly help us to resolve this.

Vignesh.

Hi, 

Is there a difference on the hardware design for the pins DIO6/DIO20 and DIO13?

How the pins mentioned are configured before the reset occurs? 

Best regards, 

Hi clement,

Clément said:

Is there a difference on the hardware design for the pins DIO6/DIO20 and DIO13?

In our custom module we brought out UART TX has DIO 13 and UART RX has DIO 12.  

Clément said:

How the pins mentioned are configured before the reset occurs? 

Here I have attached an image of TX GPIO configuration and we are not changing any configurations on runtime and before reset.

Thanks,

Vignesh.

Hi Vignesh, 

Thanks again for your patience. 

My interpretation of you issue is the following: the UART Tx line is kept high when the device is in use (cf. the SysConfig settings). When the power goes down, the line is not kept high anymore. Immediately after the power is reestablished, the line is back high. 
This is what makes the line to be read as "0xFC" or "0xFD" (i.e. 1 or 2 bits are read as "0"). 

In order to confirm this scenario, I would suggest you collect an additional trace where the reset line is also shown. 

Best regards,  

Hi Clement,

Attached are the images captured for the RST and TX signals.

Thanks

Hi Clement,

Your conclusion / Suggested work around is that to discard any data received from the device during its boot process? I mean this FD is found post reset 

Thanks

Hi Raul, 

Correct, the 0xFD data is received during the boot process, before the device is ready to work and should be discarded. 

Best regards, 

Hi Clement,

Thanks for your response.

Clément said:

before the device is ready to work and should be discarded. 

lets us know how to discard 0xFD printing on UART.

Without initializing the UART as a peripheral, the 0xFD data is received during the boot process when UART2 is configured with TX and RX pins as serialIoCfgIndex == 1, and the display TI driver is disabled.

Here I have attached an Basic_Ble_example project configured above UART2 pins.

BASIC_BLE_EXAMPLE.rar

Please can you test this project and let us know what changes required to be done for excluding the 0xFD printing on UART.

Thanks,

Vignesh.

Hi, 

This behavior is caused by the UART pin being pulled up after boot.

One option for you is to actually keep the pin low, this way the noise on the pin will not be seen as a proper UART message and will be discarded. 

I hope this will help,

Best regards, 

Hi clement,

I have kept the UART TX pin configuration Initial Output State as low and while resetting  the module even though we are receiving 0xFD data on TX.

thanks,

Vignesh.

Hi,

I am not sure I understand your message - do you mean the problem is still there? Can you share the trace you obtain? 

Best regards,

Hi clement,

Clément said:

do you mean the problem is still there?

Yes, we are receiving( 0x00 0xFF 0x00 ) message on UART upon Reset.

Can you let us know what kind of trace is required .

Thanks.