UART Booting - Can't receive data from device

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.wsdof.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
8 posts / 0 new
Last post
Ezza
Offline
Last seen:1 year 6 months ago
Joined:2017-09-07 11:33
UART Booting - Can't receive data from device

Hi,
I'm trying to boot my code using UART protocol into the DA14580 device.
I have followed the steps from: DA1458x Booting from serial interface doc.

used pins: P0_4 and P0_5
used baudrate: 57600

Followed steps:
1. Send reset request. (Length of RST pulse Tc > 10 us)
2. Read response from the device (0x02).
3. Send SOH = 0x01 to the device.
4. Send the code's length (LSB then MSB).
5. Receive ACK or NACK from the device.
6. Send code's bytes to the device.
7. Recieve CRC from the device.
9. Send ACK to the Device.

- My code fails on step 2, I don't receive anything from the device and I get a timeout.
- When probing the Rx I can see 1
- When probing Tx I can see signals (Plz see the attached images)

Is this a healthy signal on the Tx? If yes, why I'm not recieving 0x02 from the device and how can I troubleshoot the issue.

Attachment:
Device:
MT_dialog
Offline
Last seen:2 months 2 weeks ago
Staff
Joined:2015-06-08 11:34
Hi Ezza,

Hi Ezza,

Well the device upon booting it starts scanning all the peripherals (UART/I2C/SPI) there is no way of changing or altering the bootloader, what i can tell for the TX it looks like a clock signal and apparently what you get is the SCL signal from the I2C part of the bootloader on step 10. So apparently the device is out of the reset and the bootloader is executing, i am not able to see how the bootloader is executing but there is no 0x02 on the TX pin.

Thanks MT_dialog

Ezza
Offline
Last seen:1 year 6 months ago
Joined:2017-09-07 11:33
Hi,

Hi,
Thanks for the reply.
What could be the reason for skipping on step 5?
P0_4 is configured UART with the right baudrate.
I'm sending the reset, and I can't see step 5 in p0_4 signal.

What are the possible explinations for not seeing step 5 in the signal?

MT_dialog
Offline
Last seen:2 months 2 weeks ago
Staff
Joined:2015-06-08 11:34
Hi Ezza,

Hi Ezza,

Like i ve mentioned above i dont think that there is a way of skipping the UART section of the booting, if you dont see the UART STX signal the only reasonable explanation is that the tool that you are using or anything that is connected on that pin is driving the line as well. Please find attached a signal of the bootloader on the TX line.

Thanks MT_dialog

Attachment:
JJay
Offline
Last seen:3 years 2 months ago
Joined:2017-08-28 19:53
I'm having the same issue

I'm having the same issue using pins p0-4/p0-5. I'm using the pan1740 module which uses the Dialog DA14580. After power on and taking reset low, on UART-TX I get a repeated sequence as show in the first picture in the attached PDF.

If I zoom in on the spike before the five 20ms pulses I get the second picture in the PDF. This looks like it could be a 0x02 with start/stop bits, but the timing is off. This doesn't appear to be running very close to 57600 baud. Also, the voltage is idling at 1.4v. My system runs at 3.3v. I would think this should idle at either 0v or 3.3v, not in the middle. I've turned on the weak pull-up resistors in the attached processor and this idle voltage did not change. Is it being driven to 1.4v?

Does the second picture actually show the 0x02 byte?
What is the tolerance/variability of the baud rate generator?
Is there extra pacing time between bits?
Why is it idling at 1.4v?

Any help getting this working would be great!

Thank you,
JJ

Attachment:
MT_dialog
Offline
Last seen:2 months 2 weeks ago
Staff
Joined:2015-06-08 11:34
Hi JJay,

Hi JJay,

  1. Yes, it seems that its a 0x02 byte except that the fact that indeed the line idles at 1.4 Volt, which something that should not occur, at least i dont see something like this on my side.
  2. The 580 is not able of generating a baudrate of 57600, but the actual baud rate generated is 58823.529 that means that you will have an error of 2.124%
  3. 关于额外的节奏,没有there is no extra pacing, with the error the baud rate generation should give about a period of 17us per transmited bit.
  4. 正如前面提到的,我没有看到任何闲置在1.4 v,当checking on my side the line toggles between 0V and 3.3V, i suppose that something else is causing this, are you certain that when changing the pull-up configuration from the extrenal MCU didn't make any difference ?

Thanks MT_dialog

JJay
Offline
Last seen:3 years 2 months ago
Joined:2017-08-28 19:53
Found my issue. From

Found my issue. From previous work, the MCU had the UART connected to the BT module in a Low-Power mode using global power control registers. Not the normal UART config registers. Once I found this, I now receive the 0x02 byte. However, it is noted that the voltage still idles at 1.4v.

With the UART now working, the timing and signal has changed. After the 0x02 is received, the MCU receive lines stays high for roughly 60ms. It then drops down to 1.4v for 3.9ms. This appears to be followed by 5 groups of 8 sets of 10-bits (clocks?) at a higher rate than the 57600 baud USART is using. I've not zoomed in on each of these 5 groupings to know if they are all the same.

Between each group it idles at 1.4v. It then loops around and sends to 0x02 again continually repeating this sequence.

At this point I need to start added the response code and download code to the BT module.

Thank you!

MT_dialog
Offline
Last seen:2 months 2 weeks ago
Staff
Joined:2015-06-08 11:34
Hi JJay,

Hi JJay,

The reason that the line idles at 1.4V is because of the external device, the reason for that is because the pins of the 580 are configured as input pulldown during booting and the external device's lines are apparently pulled high when are configured as UART, so since before the 580's lines are configured as UART are still pulled down, and since you have an external device that will try to pull those lines high the voltage will idle somewhere in the middle of 0 and 3.3V (depending on the resistor that is used at the pull ups), but this shouldn't cause you any issues.

Thanks MT_dialog