Q: Nucleo F401 with UART bootloader

[jgriessen]

So, it sounds like this command would be good:
either define export RSHELL_PORT=/dev/ttyACM0

rshell--buffer-size=32 connect serial /dev/ttyACM0 57600

It just hangs. could not find a baud rate, so went back to
export RSHELL_PORT=/dev/ttyACM0 and using default

What causes /dev/ttyACM0 to change to /dev/ttyACM1 or /dev/ttyACM2?

A collaborator Nathan tried a blinky LED program and came across this behavior:

copy both with rshell commands:
rshell --buffer-size=32 -p /dev/ttyACM0 cp m2.py /flash
rshell --buffer-size=32 -p /dev/ttyACM0 cp boot.py /flash

press reset on the board and it will now start blinking, but it won't
respond to rshell anymore, to get that back I held the button next to
reset then also pressed reset, then released reset while still holding
the other button, then finally let the other button go.. and rshell
could again connect.

That need for reset might come from his replacement of main.py. A main interrupt service routine loop must be
part of micropython to handle the REPL, so I imagine that is the right place to add your own extra interrupts and their service routines.

Nathan figured out how to user the user button and reset to get back to a bootable state as in:
https://micropython.org/doc/tut-factory.

Is there a good place to read about
the underlying main interrupt service routine loop in micropython?

[dhylands]

What causes /dev/ttyACM0 to change to /dev/ttyACM1 or /dev/ttyACM2?

If a program opens /dev/ttyACM0 and then the board resets, then when the usb-serial port comes back it sees that /dev/ttyAM0 is still in use by the program that originally opened it, so it assigns a new number instead.

Most terminal programs don't detect the serial port going away. rshelll and usb-ser-mon both try to dectect it going away and close the port as quickly as possible so that when the usb port becomes available again it will be able to reuse /dev/ttyACM0

A collaborator Nathan tried a blinky LED program and came across this behavior:

copy both with rshell commands:
rshell --buffer-size=32 -p /dev/ttyACM0 cp m2.py /flash
rshell --buffer-size=32 -p /dev/ttyACM0 cp boot.py /flash

press reset on the board and it will now start blinking, but it won't
respond to rshell anymore, to get that back I held the button next to
reset then also pressed reset, then released reset while still holding
the other button, then finally let the other button go.. and rshell
could again connect.

What's happening here is that rshell need to use the raw repl (that's fundamental to how it works). The boot sequence of the board is something like this:

• * process boot.py
  * process main.py
  * enter the REPL (either regular or raw)

So if boot.py doesn't return then rshell can't work. If you added a 3 second delay into boot.py then every rshell command would have some or many 3 second delays added to it.

Is there a good place to read about
the underlying main interrupt service routine loop in micropython?

I guess I don't understand. There is no interrupt service routine loop in micropyton that I'm aware of. The loop is basically, run boot.py, run main.py, run the REPL and then go back to running boot.py when the REPL exits (which you can do with Control-D).

I have a long term project to have rshell use something better than than the raw repl, but this would require installing some code to run on the board.

Once we get machine.reset_cause and if that reports that the reason we were reset was to enter the raw repl, then your code could detect that and not do its regular processing. Then rshell would work.

[jgriessen]

Nathan is having trouble using a nucleo-F401RE recently made board. Is there a random chance of bad boards, or do they all act flaky
to load code through the st-link?

[dhylands]

I've definitely observed some flakiness when using stlink. Usually, just resetting and trying again is sufficient.

[jgriessen]

OK. Thanks for suggesting that other breakout board for him to use to try making some code.

http://www.ghielectronics.com/catalog/product/551 84 MHz 32-bit ARM Cortex-M4 STM32F401RET6
System Platform .Net Micro Framework
User Available Flash 128 KB


Hmmm only 128k... that will stop using the filesystem.

I need to make him a platform soon!

[dhylands]

That 128K is when using the .NET stuff it comes with (which I immediately wipe out .

The STM32F401RET6 has 512K flash (that's what the 'E' in the part number signifies. (A 'D' means 384K flash).

[jgriessen]

Thanks for suggesting this board, it will be a help. I might order one too -- but probably use the nucleo -- mine seems to flash OK several times loading the bare firmware...next, armed with your explanation of the order of files and REPL execution, I need to try writing files next.

The REPL has a loop right in its name, so it must be the built in minimal interrupt handler. If you don't send it any characters, it's not interrupted though, and your own main.py loop can do your timers and such is how I'll experiment.

For cases when you want a sequence to go in a very deterministic way, do you know if the REPL can be paused, then restarted?

[dhylands]

I've ordered one - it should be here by the end of the week.

I'll put together a G30TH board definition. It looks like the pins for the G30HDR are totally different from the G30TH.

[jgriessen]

Dang! If you're doing a board def., I need one of those boards too, just for the following along speedup it will give in making a board def for my version with pulsers, ADCs looking at voltage dividers down from high volts, and a USB connector just like the G30TH.

[nmz787]

Thanks for suggesting this board, it will be a help. I might order one too -- but probably use the nucleo -- mine seems to flash OK several times loading the bare firmware...next, armed with your explanation of the order of files and REPL execution, I need to try writing files next.

To be clear, it was copying .py files to the already-firmware-flashed MCU... actually flashing the micropython interpreter was not an issue, and it was something I only did two or three times (before learning about the user and reset button combos to get the REPL back if you load bad code or the board hangs while copying a .py file)