Skip to content
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

Testing with Teensy MicroMod doesn't work properly #73

Open
collin80 opened this issue Jan 17, 2022 · 0 comments
Open

Testing with Teensy MicroMod doesn't work properly #73

collin80 opened this issue Jan 17, 2022 · 0 comments

Comments

@collin80
Copy link

When using the code as-is there are a couple of issues with the Teensy MicroMod.

1: The product ID for soft reset is hard coded to be the default "Serial" type with one serial port. But, quite a variety of product IDs possible will work with the existing soft reset code. It appears any of them that have the first serial port will work just as well. I ran into this when trying to flash a program that uses "Dual Serial". I basically check all IDs that I thought should work and it runs through them seeing if any match the connected hardware. This works. I can submit a pull request for doing this if it sounds like this would be desired in the mainline code

2: Whether soft reset is done or I push the button to manually trigger the HalfKay bootloader, the first attempt will fail like so:

collin@:$ ./teensy_loader_cli --mcu=TEENSY_MICROMOD -v -s -w GEVCU7.hex
Teensy Loader, Command Line, Version 2.2
Read "GEVCU7.hex": 272384 bytes, 1.6% usage
Error opening USB device: No error
Waiting for Teensy device...
(hint: press the reset button)
Found HalfKay Bootloader
Read "GEVCU7.hex": 272384 bytes, 1.6% usage
Programming...error writing to Teensy

That is, it gets three dots then errors out. I have traced this down to 0.5 seconds being too short. If I enlarge the 0.5 second timeout to 1.5 seconds it will always work the first try. In fact, after doing so, I can indeed see three dots, a quick pause, then the rest of the dots fly by at full speed. Before I changed the timeout I was still able to flash by attempting a second time. The second time the board was already in the bootloader and it never faulted. So, something is taking more time, at least on the TeensyMM right at the three dots point. More timeout allowance fixes it. Is there any objection to lengthening the timeout as I have done? Surely a 1.5 second timeout won't hurt anything?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant