Just to confirm, the only time I need to use those buttons are for when getting Zadig to detect the board, on Windows?
Technically, you can use the RebootDFU
command in the serial monitor instead, so you don’t really need the buttons to run zadig. The default instructions are to use the buttons because some people have problems with the serial monitor and it’s driver, so they can’t use RebootDFU
.
However, since the buttons are small and fiddly, maybe RebootDFU
is easier…
The only time you HAVE[1] to use the buttons are if you have a bad program on the board. This can happen in two ways:
- Your program gets interrupted while uploading to the board
- A bug in the program makes the board crash nearly immediately after boot (or after connecting to a computer)
If one of these two things happens, there is no way to fix it without using the buttons.
[1] Unless you have a st-link v2, in which case you can program the chip that way…
I now have ProffieOS running properly on a teensy micromod board, with sound, sd card, buttons, motion and neopixel support.
Time to swap out the CPU.
I think I might try an RP2040 first.
Do you mean teensy 4?? Is there a working branch I can look at?
The micromod teensy is indeed a Teensy4 processor. All the code is on the master branch on github, and all the drivers work, but since there is nothing like a teensysaber board for Teensy4 (yet), there is no ready-made configuration or hardware. You can look at config/micromod_teensy_config.h to get started though.
I’ve started playing around with the latest from master. I’ve tried before w/ the Teensy 4.1, but I had trouble just getting it to talk nice to the SD card (it would lose access after a while).
This time it works well, except for the motion chip. I have the Teensy 4.1, MAX98357A, neopixel (just 1 to test), and MPU6050. The sound/light/SD works fine, but the motion has issues. It will connect and start, but very soon after it will start having timeouts when reading status_reg (it ends up -1). It will keep rebooting the motion chip endlessly.
I’ve tried lowering Teensy CPU speed and/or lowering the wire baud rate, but neither stabilizes things. This same setup works fine on the Teensy 3.x. Doesn’t look like there’s nearly any 4.x-specific code in the I2C* libs, so not sure what’s going on.
Is there anything I can do to help debug? Or is this more of a problem with my specific setup?
My guess is that the MPU6050 code has a bug that prevents it from recovering properly.
On a Teensy 3.x, we use the i2c_t3 library, which has it’s own recovery routines, so maybe that’s why it works better there.
I haven’t tested the MPU6050 code myself, and the code is fairly old, so the chance of bugs is fairly high.
Thanks, even that gives me some pointers; if I remove all the i2c code and just do a simple “read from MPU6050” type demo, it will keep reading MPU data without any timeout issues. So I just need to backtrack from here to see what in the I2C is interfering.
STM32BOOTLOADER needs the driver WinUSB (6.1.7600.16385)
What is the correct driver for the board when it’s a “Proffieboard” ?
A Proffieboard is a composite USB device, which is kind of like software version of a USB hub. Each part of the composite device has it’s own driver. Depending on what you pick in Arduino → Tools → USB type, the parts are:
- ACM Serial, for which the driver should be usbser.sys
- WebUSB device, which I think should have a winusb driver
- Mass storage device (driver problems are unusual here, so I don’t remember what driver it’s supposed to have.)
I’ve now gone through all my micromod CPUs.
I may be picky, but apart from the Teensy4 one, I don’t really like any of them.
Mostly it’s a matter of lacking good software library support. Most of them lack I2S and SDIO support, and some don’t have WS2811 code either.
I might give this another go later, but for now I think I’m going to give up on using another cpu family for a while and focus on other projects.
Just curious if there’s a way to programme the board with this Wireless_Programming_Module_For_Arduino__SKU_TEL0037_-DFRobot.
That board is basically a remote serial port, similar to a BT chip.
There is currently no way to program a proffieboard from a serial port.