-
Notifications
You must be signed in to change notification settings - Fork 278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected glitch on CW-Nano Serial TX line #394
Comments
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 Alex |
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? |
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 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 |
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))
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. |
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 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. |
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:
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:
![cw-nano-tx-glitch](https://user-images.githubusercontent.com/652934/160300813-7f8edfb3-4c0b-41be-99a8-d254445a76eb.png)
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.
The text was updated successfully, but these errors were encountered: