Unexpected glitch on CW-Nano Serial TX line

[mringwal]

While trying to get Act 2 in Chapter 6 of the HHHB to work, I've stumbled upon an unexpected behaviour of the the serial tx line of the CW-Nano. After toggling the Reset Out line I can see a short (12.5 us) glitch on the serial TX line, which I did not expect and which causes the serial bootloader in the LPC1114 to respond with an unexpected baud rate.

Setup:

• CW-Nano with current firmware
• Logic 16 connected to: GND, Reset Out (J3-5), Serial TX (J3-10)

Script (stripped version from book)

`PLATFORM="CWNANO" %run "Helper_Scripts/Setup_Generic.ipynb"

import chipwhisperer as cw import time

p = prog() p.scope = scope target.dis() scope.dis()

scope = cw.scope() target = cw.target(scope) scope.io.tio1 = "serial_rx" scope.io.tio2 = "serial_tx"

target.baud = 57600 scope.io.nrst = 'low' time.sleep(0.01) scope.io.nrst = 'high' time.sleep(0.1) target.ser.flush() `

Now, I see this:

Here's the Salea Logic 2 trace: Logic2.sal.zip

I was able to use another USB-to-UART adapter to communicate with the bootloader, but I'd be curious what's causing this glitch and if it could be avoided.

[alex-dewar]

Hi,

I believe this is caused by the baud rate change. I'll see if I can fix it, but for now, can you try adding a delay between changing the baud rate change and resetting the target?

Unrelated, but I'd avoid assigning the scope object to things, then disconnecting, as that destroys the USB connections, meaning you'll run into errors if you try to use it (p.scope = scope; scope.dis())

Alex

[mringwal]

Thanks for the quick response. I've tried adding a delay after the baud change as well as removing the baud change altogether. The TX glitch happens stubbornly around 1.4 ms after the Reset toggle.

I've tried to toggle the Reset line twice and get the TX glitch again after the same time, so it seems to be related to the actual Reset toggle action (although I have no idea why that would be).

Also thanks for the hints with the API. I admit that I don't understand them yet and just tried to provide a "working" (as in, it shows the issue) script. When removing more lines from the script, the Reset toggle didn't work, so I've left it at a reasonably small length.

[alex-dewar]

Hmm, I can't replicate that behaviour. Running

scope.io.tio1 = "serial_rx"
scope.io.tio2 = "serial_tx"

scope.io.nrst = 'low'
time.sleep(0.01)
scope.io.nrst = 'high'
time.sleep(0.1)
target.ser.flush()

doesn't cause either of the serial lines to toggle for me.

EDIT: Just had a thought: do you have the target board separated from the Nano? If not, is it possible you have some firmware running on the target that toggles the IO pins? Also, are you scoping this out while connected to the LPC board? If you're connected, can you disconnect from the LPC board and verify that this still happens?

[mringwal]

Weird. Could you run the full (albeit clumsy) script?

The STM32 target should have been erased several times using the script from the book. I see 'Detected known STMF32: STM32F04xxx Extended erase (0x44), this can take ten seconds or more' TRUE'

The LPC1114 is disconnected, only the Salea connected to GND, Reset Out and Serial TX. I wasn't aware that the tio1 and tio2 are connected to the target board (although the name implies it). I didn't mention it, but I have the same glitch also on the Serial RX line, but didn't bother as it should be input. Is there a simple way via Python API to read out the target Flash? (compared to hooking up a J-Link).

EDIT: After your suggestion that it might be caused by the on-board target, I've removed the assignments scope.io.tio1 and scope.io.tio2 as well as the target.ser.flush() call. The behaviour stays the same.

[alex-dewar]

Yeah trying your full script shows the same behaviour I observed earlier. You should be able to get firmware off the target by running:

PLATFORM="CWNANO"
%run "Setup_Scripts/Setup_Generic.ipynb"

import chipwhisperer as cw
import time

scope.io.tio1 = "serial_rx"
scope.io.tio2 = "serial_tx"
p = prog()
p.scope = scope
p.open()
p.find()

with open("nano_fw.bin", "wb") as f:
    data = p.stm32prog().readMemory(0x8000000, 32767)
    f.write(bytearray(data))

EDIT: After your suggestion that it might be caused by the on-board target, I've removed the assignments scope.io.tio1 and scope.io.tio2 as well as the target.ser.flush() call. The behaviour stays the same.

Yeah, if it's the target that's causing this, I wouldn't expect that to change anything. It's not possible to disconnect any pins from the target without cutting traces. All avoiding that assignment does is leave whatever that pin is set to in the SAM4SD as its default.

[mringwal]

Thanks for the script to read out the flash of the target. It run and I got a 32k file with '0xff's - so this confirms that the script to erase the STM32 works, which is a good thing in general.

It still doesn't explain the glitches on tio1 and tio2 :(

However, the main motivation for posting this issue was that it looked like a general issue that would be good to fix for everybody. If it only happens for me, I can also use a separate FTDI-UART adapter.

The CW-Nano product page mentions You have two options for connecting to external targets: to either break off the STM32F0 end, or to program it with a loop that keeps all I/O in tristate mode

My understanding is that an erased flash (0xff..) should not cause any change to the GPIOs and that GPIOs should be in tri-state mode on the STM32F0. Could you check with an erased STM32F0, or, if you have, point me to a minimal firmware for the STM32F0 that keeps GPIOs in tri-state and puts itself to sleep asap.