Medicine Timer

User avatar
LightningStalker
Posts: 21
Joined: Fri Nov 03, 2017 5:00 am
Location: GRMI
Contact:

Re: Medicine Timer

Post by LightningStalker » Sat Nov 04, 2017 6:47 am

Ok I finally got it working, at least I was able to upload a sketch over USB. Apparently the latest version of st-flash is slightly incompatible with the latest ST-LINK firmware. It flashes and verifies once just fine, but it has to be power cycled every time you want to flash something, and reading back the firmware results in some garbled data.

To get the blink sketch to upload though, I had to press the reset button at just the right time. dmesg was saying that the PID was going from 0003 to 0004. It takes quite a few tries because it doesn't stay in DFU mode for very long and dfu-util quits immediately if it doesn't find anything. It's basically the same issue as the one described in this thread. Everything is set up correctly in the IDE.

So here are the settings

Image

And here is what happens when I attempt to upload without pressing reset

Code: Select all

"/home/robert/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-objcopy" -O binary  "/tmp/arduino_build_458303/Blink.ino.elf" "/tmp/arduino_build_458303/Blink.ino.bin"
Sketch uses 13044 bytes (19%) of program storage space. Maximum is 65536 bytes.
Global variables use 2816 bytes (13%) of dynamic memory, leaving 17664 bytes for local variables. Maximum is 20480 bytes.
/home/robert/.arduino15/packages/stm32duino/tools/stm32tools/2017.11.2/linux/maple_upload ttyACM0 2 1EAF:0003 /tmp/arduino_build_458303/Blink.ino.bin 
setRTS(): TIOCMSET: Broken pipe
Failed to open serial device.
No DFU capable USB device found

dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Filter on vendor = 0x1eaf product = 0x0003
Waiting for /dev/ttyACM0 serial...Done
The problem seems to be this line in particular

Code: Select all

setRTS(): TIOCMSET: Broken pipe
Failed to open serial device.
Search results say that this happens when "the IDE" attempts to reset the board over serial and something goes wrong. So I went a little further and found out that the maple_upload script is running an elf binary called upload-reset. I think this may be as far as I can trace it.

Manually resetting the board and then running upload-reset at first results in only the

Code: Select all

Failed to open serial device.
message. Running it a few more times it eventually finds the serial port and does something for a few seconds then quits with no message and the board does not reset. Further attempts to run it only result in the above broke pipe message. There is also a message in the kernel ring buffer.

Code: Select all

$ dmesg | tail -n2
[102358.298785] cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device
[102382.815425] cdc_acm 2-1.2:1.0: failed to set dtr/rts
After hours of fiddling around with upload-reset I have come to the conclusion that either the kernel or my hardware doesn't like something about the reset sequence. Commenting out line 145 of upload-reset.c makes it "work", but then obviously it won't reset the dev board.

I reproduced the sequence in a slightly different way and it happens in the exact same place in the exact same manner, so it's definitely something hardware or kernel related.

Stranger still, I can send the sequence to Arduinos and a PL2303 with no problem. Unfortunately I don't have another STM32 board to test this on.

***Update
After hours and hours of getting nowhere, searching desperately for the serial code in this giant duino library, I finally just gave up. Then I found this viewtopic.php?f=22&t=2145&p=29018&hilit=dtr#p29028
So there is hope after all. I'm just not doing it right now. I am too tired.

User avatar
ahull
Posts: 1650
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: Medicine Timer

Post by ahull » Sun Nov 05, 2017 12:57 am

By way of a little encouragement, here is my take on using the STM32 as a timer, in my case as a sunset/sunrise timer.

https://github.com/pingumacpenguin/STM32-Sunrise

https://hackaday.io/project/2126-sunset ... controller

There are also a couple of useful threads about using the STM32 built in RTC and adding a battery for the RTC and the associated NVRAM somewhere on this forum.
- Andy Hull -

User avatar
RogerClark
Posts: 7447
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Medicine Timer

Post by RogerClark » Sun Nov 05, 2017 5:13 am

As you have a STLink.

Assuming it is definitely working, I would select ST-Link upload and just try to get a blink sketch working.

Once blink works, try sending something to USB Serial e.g. in a loop, I call it blink and count.

And look to see if Linux recognises the USB Serial device and lets you open it etc

If that all works, then go back to trying the bootloader

With the bootloader, the IDE sends a magic-number reset sequence to the board, which the sketch (core) intercepts and reboots the board.

This causes it to run the bootloader, and DFU-Util can the upload the new sketch

This does however rely on the PC (including linux) noticing that the USB device has changed from Serial to DFU, and this in turn, relies on the USB D+ line having the correct 1.5k pullup resistor to 3.3V
The Ugly board is a really bad board to start with, and its possible that it has faulty usb or no pullup or the wrong value etc.

I'd recommend you get hold of a Maple mini and / or a Blue Pill.

The Maple mini is the best board to get if things dont work, as they come pre-installed with the bootloader and they also have the correct USB reset hardware (better than the 1.5k pullup, which is the bare minimum that normally works)

User avatar
LightningStalker
Posts: 21
Joined: Fri Nov 03, 2017 5:00 am
Location: GRMI
Contact:

Re: Medicine Timer

Post by LightningStalker » Sun Nov 05, 2017 2:06 pm

Thanks for the tips. I did as you said and here are the results.

Switching to ST-LINK mode
Blink - works
Blink and count - works, I see the numbers in the serial monitor
Linux - the serial port is there, I can see the output in miniterm
bootloader - still same as before, the LED on PB1 begins flashing rapidly and the serial port stops responding, continues indefinitely

So does that mean the STM32 reset into bootloader mode and the PC just isn't detecting it? I have no idea what booloader mode is supposed to look like. When I press the reset button, the kernel ring buffer says it gets redetected and everything comes back. So it might be possible to reset the USB without a circuit like what the Maple Mini has. If that is the case, then it's a matter of deciding where to do it, the serial code or the bootloader.

Looking at the board, R13 is a 152, so that should be the proper 1.5k resistor.

I bought the Ugly board instead of one of the other pills is because it's the only one that has the proper filtering on VDDA, at least as far as I know. The genuine Maple Mini did have it, but they don't seem to be available anymore and the clones do not. The whole reason I decided to get into STM32 is because of the fast 12-bit ADC they have.

https://youtu.be/F8bC-xqPcXE

In any case I bought a couple Black Pills, but it will be a while before they arrive here from China.
Last edited by LightningStalker on Mon Nov 06, 2017 1:15 pm, edited 1 time in total.

User avatar
RogerClark
Posts: 7447
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Medicine Timer

Post by RogerClark » Sun Nov 05, 2017 8:59 pm

The problem sounds the same as some guys running OSX are having.

The PC is taking a long time to notice that the big board has switched back to the bootloader and is now a DFU device.

There are various fixes, because the bootloader has a feature to lock it in DFU following reboot if the battery backed RAM has a magic number in a specific location.

I am not at my main computer now, so can’t find the details of how the Mac guys did their workaround, but it’s a relatively recent thread, so take a look in the active threads and you should probably find their code

Note I wanted to add this feature as standard, but there was resistance from some community members to this.
However as this problem is more more widespread I think I will have to investigate making it the standard system in the core.

User avatar
LightningStalker
Posts: 21
Joined: Fri Nov 03, 2017 5:00 am
Location: GRMI
Contact:

Re: Medicine Timer

Post by LightningStalker » Sun Nov 05, 2017 9:12 pm

Thanks, this is beginning to become clear to me what is happening. I will go see if I can find that thread when I get a chance.
RogerClark wrote:
Sun Nov 05, 2017 8:59 pm
The PC is taking a long time to notice that the big board has switched back to the bootloader and is now a DFU device.
It isn't just taking a long time, it doesn't detect it at all, ever. All it sees is a frozen serial port for as long as it's attached unless the reset button is pressed.

The other thing about it is that it happens before the 'magic' sequence is completed. It appears to be already resetting before line 145 in `upload-reset.c`.

User avatar
RogerClark
Posts: 7447
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Medicine Timer

Post by RogerClark » Sun Nov 05, 2017 11:09 pm

Which bootloader variant are you using.

Some variants have a "button" pin defined

https://github.com/rogerclarkmelbourne/ ... #L156-L158

So if the variant you are using has the optional button enabled, you can pull the pin high or low (depending on whether the config is active high or low for the button), and it will hold in the bootloader (DFU) until an upload is complete

i.e If you pull that pin high, then get the board to reset via the IDE it should stay in DFU long enough for you to run the linux command to check whats on the USB bus (I forget the syntax)

Then, if it does not re-enumerate, the problem is the USB pullup on the board.

Note.

The USB reset relying on the pullup, is not technically the correct way to do it, there is supposed to be an external reset circuit on USB D+ (see the Maple mini schematic), which is controlled via another GPIO on the MCU

But hardly any of the chinese made STM32 boards have the correct USB reset hardware, so we use a workaround which involves briefly changing the pinMode on USB D+ from a USB pin to a GPIO pin and we drive it LOW, and the set it back to a USB pin.

This normally works and the host PC sees the change, but its not guaranteed to work on all host systems

Anyway, in your case it looks like there is a problem with the USB D+ pullup or some other hardware fault.

User avatar
LightningStalker
Posts: 21
Joined: Fri Nov 03, 2017 5:00 am
Location: GRMI
Contact:

Re: Medicine Timer

Post by LightningStalker » Tue Nov 07, 2017 2:45 am

RogerClark wrote:
Sun Nov 05, 2017 11:09 pm
Which bootloader variant are you using.
binaries/generic_boot20_pc13.bin
RogerClark wrote:
Sun Nov 05, 2017 11:09 pm
Anyway, in your case it looks like there is a problem with the USB D+ pullup or some other hardware fault.
I thought so too, but it looks like there is something more going on here. The pullup resistor meters in at 1460Ω, which is only -1.03% if I'm doing my math right. I changed the LED to pin PC13 where it was supposed to be (all the LEDs on the different variants had me a bit confused) and tried uploading over USB with the IDE again, and the LED does not flash. It does flash when I either press the reset button or cycle power. What does happen is PB1 starts pulsing rapidly and the serial port freezes.

The button pin in this case is PB14, active high. Driving PB14 high does indeed keep it in bootloader mode. PB13 flashes and I am able to upload code, but trying to reset again through the IDE still results in the pulsing on PB1, port freeze, nothing on PB13, and other symptoms described heretofore.

Maybe I should make a video.

User avatar
LightningStalker
Posts: 21
Joined: Fri Nov 03, 2017 5:00 am
Location: GRMI
Contact:

Re: Medicine Timer

Post by LightningStalker » Fri Nov 10, 2017 1:45 pm

Well I tried st-util and OpenOCD and everything I try to do it just repels it. I don't know what is going on.
If the chip is bad, it's failed in the strangest partial way. I can upload code to it, the LED flashes, the bootloader works, but I can't get the debugger to attach properly and the weird failure during reset with the pulsing on PB1.
Unless I'm not doing the debugger right, I don't know I've never tried to debug one of these before.

In OpenOCD, to get it to connect, I have to hold the reset button down. Then once it jumps to the user code (in this case BlinkNcount) I get this:

Code: Select all

Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 6300ms
Is the core doing something funny on the JTAG port? How am I supposed to debug something if the JTAG screws up when it jumps to the code I'm trying to debug? I have Optimize set to Debug (-g) that is correct for debugging yes?

User avatar
Pito
Posts: 1627
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Medicine Timer

Post by Pito » Fri Nov 10, 2017 3:17 pm

I messed with the bootloader stuff recently, so I had to refresh my understanding too:

1. bootloader: with the above bootloader, the stuff works with BluePill (and friends):

a. it works fine with 10k resistor on D+ here,

b. upload via IDE: when the USB COM number is not set correctly, the upload needs reset button to be pressed when the upload starts (or power off/on), afterwards the Serial starts (the Maple Serial mode) automatically (you get serial COM available, you can communicate)

c. otherwise in order the Serial starts to work you have to press reset or power off/on

d. USB enumeration: it works such the USB pin D+ is pulled down for a while (say a ~microsecond long pulse, the pullup is the 10k resistor) and then the pin is set as input - that happens during the start upon reset (or power off/on) - that pulse is generated in sw, you may find the pulse in our sources:
Arduino_STM32/STM32F1/variants/generic_stm32f103c/wirish/boards_setup.cpp - line 96
- that short pulse signals to the PC host via USB the BPill is there and alive

If you mess with sources mind the GENERIC_BOOTLOADER must be defined, otherwise no pulse will be generated

2. your board must have the both input pins Boot0 and Boot1 set to log0 (low),

3. the Maple USB drivers - Maple DFU driver for upload, and Maple COM for Serial - must be installed successfully,

4. JTAG: we do not use jtag, we do use SWD interface for debugging (or STLink programming) instead.

EDIT: Fixed Serial.begin() info.
Last edited by Pito on Fri Nov 10, 2017 8:06 pm, edited 20 times in total.
Pukao Hats Cleaning Services Ltd.

Post Reply