Reset + serial input interaction?

This is on a Maple mini with bootloader V2. Using it’s USB to program. Boot1 pin pulled down with 10K.
New to STM32 as such and amazed at how easy it has been for me to get this all up and running, thanks to all the work, time and software that has been made available .. has to be a thanks for that.

Anyway, I have 4 timers, two serial ports , LCD drive and ppm outputs all running very nicely. It’s just that there may be a possibility of data being pumped into a serial RX port upon a reset. This causes what appears to be a ‘perpetual’ bootloader mode?
I cannot, as yet, find any detail as to the interaction of reset whilst serial data present, so would really appreciate any clarification on this.

The only route I can imagine at the moment is to take the signals into input pins, then out again in to the RX pins, and manipulate the outputs in software such that no signal is present at reset time. Hopefully not!

thanks for any help with this

Dave

Yes, simple biased ‘or’ mosfet and output pin to turn off pull down sorts it.

Dave

The IDE resets the board via USB serial, by sending a magic sequence of bytes, which is intercepted by the USB serial RX code.

However in your case it sounds like the board is somehow getting reset by data arriving on a hardware serial UART.

Or did I miss understand the problem ?

Thank you for replying Roger…
It’s still early days and a learning curve for me at the moment, along with those associated frustrations of not finding the info you want when you need it, only to be shown that it is in fact staring you in the face! I’m sorry if this is the case!

No, the loop occurs after the code has been uploaded, all is running well and external serial data is incoming. Checking what happens if a reset occurs… could be for a variety of reasons.(power glitch etc) On a reset, if the serial data is present, a return to normal operation fails with the led fast pulsing stuck in a loop.
Remove the serial input and the reset process restores the running program.
This occurs on any RX port.

I guess this is due to allowing ease of start up programming etc, and it’s my lack of understanding of how easy you have made all this.

I note that with the mini, there are a few pins that appear to really need either external pullups(downs) to secure integrity.
One of the ‘minis’ attached to an rf receiver, just dealing with reading pulse width streams sent to it, will randomly go into this startup loop mode after the another mini, which drives the rf transmitter, gets reset. I am looking at this today. and will probably find open pins not helping.

Getting there slowly … but get there I will!

thanks again ….

The Maple mini comes pre-flashed with a bootloader to make it easier to use (as it doesnt need any external hardware to upload the code)

If you have a USB to Serial and attach it to RX1 and TX1 then press and hold the button while pressing and releasing the Reset button, it goes into the MCU’s own internal serial bootloaeder and you can upload via an external USB to Serial

But in this case you need to select the Generic STM32F103CB board, as the Maple mini board option does not have a serial upload option, and the MCU it uses is the F103CB

But… There is a hardware design fault and you need to pull pin boot1 low (as it floats)

If you upload that way you don’t have a bootloader in the MCU, and code is run from the start of flash (0x8000000)

(Note this erases the bootloader, but you can reinstall via USB to serial)

Or if you happen to have a STLink programmer you can upload that way as well

However none of this really accounts for your crash / glitch situation.

Thanks Roger ….

Well, at least I haven’t hit a brick wall yet, and have a few things to try.
All part of building a better understanding, leaving less surprises to come! (no doubt there will be a few).

Dave

BTW

It’s just that there may be a possibility of data being pumped into a serial RX port upon a reset. This causes what appears to be a ‘perpetual’ bootloader mode?

I think its not entering the bootloader, is more likely that there was an ASSERT triggered in the code, as in some instances this causes the code to execute a “strobe” function which fades the LED up and down (not merely turning it on and off).

I’ve not had an issue with the code Asserting for ages (nor had anyone else) but it is a possibility.

From memory, if it does Assert, it may also attempt to drive some debug text to one of the UART ports (possibly UART2 but I really can’t remember the details)

I’m afraid if it is ASSERTing, its going to be hard to find out why, without a STLink or Blackmagic probe, where you can do in circuit debugging, as if you run either of them, the ASSERT normally also triggers GDB to halt on the error.

Anyway, if the LED is fading in and out, you may need to search the core code looking for places where it may be causing an ASSERT

Yup, I think that is actually what is happening….. high frequency pwm on the led, varying consistently.
Typical .. STLink at work! (semi retired here).
Well, at least I know what to look for! Asserting hmmm?
Time for some more learning….

Thanks for spending your time on this. I appreciate it.

Dave

Hi Dave.

No worries

Sorry I can’t be more help, but we’ve not see any Asserts occur for a long time, and I actually was going to remove them, as it is often better if the MCU causes a debugger exception as its easier to debug than an Assert

I’m not sure if you have a STLink, but if you don’t you can make a BlackMagic probe from another STM32f103 (Actually, you can make a STLink from a STM32F103 board, but the process is not legal as STM have not actually released the STLink binary. But some russian sites are known to have copies)

Just be sure that BOOT 0 is tied to GND at reset.
Otherwise, when BOOT 0 is “1” and BOOT1 is pulled down, the chip may interpret incoming data on serial within 3 seconds from reset as a try to program the chip (as it will boot from system memory).

I think boot0 is pulled low on the Maple mini, but as you know Steve, there is a design fault with Boot1

But I think somehow the problem is an Assert being caused somewhere in the core and the problem is no a reboot

I did a search of the whole core for Assert, but its used in quite a few locations e.g.

Search "Assert" (360 hits in 59 files)
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\ext_interrupts.cpp (1 hit)
Line 88: ASSERT(0);
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\HardwareSerial.cpp (2 hits)
Line 133: // ASSERT(baud <= this->usart_device->max_baud);// Roger Clark. Assert doesn't do anything useful, we may as well save the space in flash and ram etc
Line 133: // ASSERT(baud <= this->usart_device->max_baud);// Roger Clark. Assert doesn't do anything useful, we may as well save the space in flash and ram etc
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\HardwareTimer.cpp (1 hit)
Line 67: ASSERT(this->dev != NULL);
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\libmaple\bkp_f1.c (2 hits)
Line 83: ASSERT(0); /* nonexistent register */
Line 102: ASSERT(0); /* nonexistent register */
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\libmaple\dma.c (1 hit)
Line 79: ASSERT(0); /* Can't happen */
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\libmaple\dma_f1.c (9 hits)
Line 142: ASSERT(_dma_addr_type(cfg->tube_src) == DMA_ATYPE_MEM);
Line 204: ASSERT(0);
Line 220: ASSERT_FAULT(!dma_is_channel_enabled(dev, channel));
Line 234: ASSERT_FAULT(!dma_is_channel_enabled(dev, channel));
Line 269: ASSERT(status_bits & 0x1);
Line 273: ASSERT(status_bits != 0x1);
Line 289: * the debug level is too low for the above ASSERTs() to have had
Line 299: ASSERT_FAULT(!dma_is_channel_enabled(dev, channel));
Line 308: ASSERT_FAULT(!dma_is_channel_enabled(dev, channel));
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\libmaple\exti.c (1 hit)
Line 119: ASSERT(handler);
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\libmaple\i2c.c (3 hits)
Line 179: ASSERT(!(dev->regs->CR1 & I2C_CR1_PE));
Line 229: ASSERT(dev->state == I2C_STATE_IDLE);
Line 389: ASSERT(0);
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\libmaple\rcc_f1.c (2 hits)
Line 104: ASSERT(sysclk_src == RCC_CLKSRC_PLL &&
Line 129: ASSERT_FAULT(!rcc_is_clk_on(RCC_CLK_PLL));
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\libmaple\timer.c (5 hits)
Line 218: ASSERT_FAULT(channel > 0 && channel <= 4);
Line 221: ASSERT(dev->type != TIMER_BASIC);
Line 259: ASSERT((1 <= channel) && (channel <= 4));
Line 399: ASSERT(0);
Line 447: ASSERT_FAULT(0);
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\libmaple\usart_f1.c (1 hit)
Line 174: ASSERT(clock_speed);
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\libmaple\usb\stm32f1\usb.c (1 hit)
Line 316: ASSERT_FAULT(epr & USB_EP_CTR_TX);
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\libmaple\util.c (10 hits)
Line 43: * ASSERT() will also throb() an LED connected to that port and pin.
Line 60: * Print an error message on a UART upon a failed assertion (if one is
Line 63: * @param file Source file of failed assertion
Line 64: * @param line Source line of failed assertion
Line 65: * @param exp String representation of failed assertion
Line 73: /* Print failed assert message */
Line 74: usart_putstr(err_usart, "ERROR: FAILED ASSERT(");
Line 88: * Provide an __assert_func handler to libc so that calls to assert()
Line 88: * Provide an __assert_func handler to libc so that calls to assert()
Line 91: void __assert_func(const char* file, int line, const char* method,
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\pwm.cpp (1 hit)
Line 47: ASSERT(dev && cc_channel);
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\stm32f1\util_hooks.c (1 hit)
Line 42: /* Failed ASSERT()s send out a message using this USART config. */
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\stm32f1\wirish_digital_f1.cpp (1 hit)
Line 76: ASSERT(0);
D:\Documents\Arduino\hardware\arduino_stm32\STM32F1\cores\maple\usb_serial.cpp (2 hits)
Line 60: ASSERT(0);
Line 354: ASSERT_FAULT(0);


OK, I may misunderstand something.
According to spec, the chip should run code from flash when BOOT 0 is “0”, independent of BOOT 1 state.
So you say that even if BOOT 0 is “0”, the chip may react in an unexpected way to input serial data during boot/reset/initialization?
EDIT
It would be interesting to catch data ouput over serial Tx, if any, in the fault case.
Furthermore, I think only asserts for exti, usb or serial would be of interest, the rest seems to be not relevant.

Oh well. Just found my problem …. Sorry all, stupid error on my side. Trapped a condition that would arise when the ‘receiving’ mini was presented with particular incorrect frame data after the sender unsync’d reset, that would cause an overspill into the receiver data array, thus writing into unknown territory and hence the response.
Again, thanks for the help …. every failure has a positive though, and at least I have learnt some useful facts here.