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

Prevent MCU from booting between pymcuprog commands? #42

Open
nabelekt opened this issue Mar 1, 2024 · 4 comments
Open

Prevent MCU from booting between pymcuprog commands? #42

nabelekt opened this issue Mar 1, 2024 · 4 comments

Comments

@nabelekt
Copy link

nabelekt commented Mar 1, 2024

I run two commands in sequence:

pymcuprog write  --tool uart --uart /dev/ttyUSB0 --clk 230400 --device avr128da32 --memory fuses --offset 0x05 --literal 0xCC
pymcuprog write  --tool uart --uart /dev/ttyUSB0 --clk 230400 --device avr128da32 --filename gnss_power_test_psmoo.hex --erase

and may add:

pymcuprog verify --tool uart --uart /dev/ttyUSB0 --clk 230400 --device avr128da32 --filename gnss_power_test_psmoo.hex

I do this very often. My problem is that between the two commands, the previous program starts running. I need it not to. Is there any way to prevent this programmatically, and keep the MCU from booting between commands? I think maybe the RESET line would need to be held LOW?

Thanks for this tool! It is immensely helpful.

@nabelekt nabelekt changed the title Keep MCU from booting between pymcuprog commands? Prevent MCU from booting between pymcuprog commands? Mar 1, 2024
@xedbg
Copy link
Contributor

xedbg commented Mar 5, 2024

Hi @nabelekt - unfortunately there is currently no way to prevent the MCU from running. A modern AVR does not always have a RESET line, and its also not known whether the debugger even has control over it.
Since fuses are not erased by a chip erase on an AVR, is it an option to use the --erase command on the fuse write (after which the MCU will run NOPs) and then write the flash on the second command without --erase? Alternatively you could use an intel-hex tool to combine the fuses into the flash image...

@nabelekt
Copy link
Author

Thanks for the suggestion, @xedbg. I finally got around to giving it a go. I tried running this as my first command

pymcuprog write  --tool uart --uart /dev/ttyUSB0 --clk 230400 --device avr128da32 --memory fuses --offset 0x05 --literal 0xCC --erase

But that returned the error here:

Connecting to SerialUPDI
Pinging device...
Ping response: 1E9709
pymcuprog.pymcuprog_main - ERROR - Erase switch (--erase) is only supported when writing a hex file!

I figure I can do this instead:

pymcuprog erase  --tool uart --uart /dev/ttyUSB0 --clk 230400 --device avr128da32
pymcuprog write  --tool uart --uart /dev/ttyUSB0 --clk 230400 --device avr128da32 --memory fuses --offset 0x05 --literal 0xCC
pymcuprog write  --tool uart --uart /dev/ttyUSB0 --clk 230400 --device avr128da32 --filename 2_USART.hex

It makes the programming process longer than I'd like, but it does work. Any particular reason why we can't erase when writing fuses?
Any other suggestions?
Thanks!

@xedbg
Copy link
Contributor

xedbg commented Apr 12, 2024

@nabelekt - I think we just did not consider this use-case when adding the --literal write. We can consider this as a feature-request going forward.
Regarding programming 'speed' - have you tried tweaking the --uart-timeout TIMEOUT argument? This could at least reduce the initial handshake time.

@nabelekt
Copy link
Author

nabelekt commented Apr 12, 2024

I think we just did not consider this use-case when adding the --literal write. We can consider this as a feature-request going forward.

Please do. It would also be great if we could write both fuses and a program in a single command.

Regarding programming 'speed' - have you tried tweaking the --uart-timeout TIMEOUT argument? This could at least reduce the initial handshake time.

This indeed does help quite a bit! --uart-timeout 0.1 on each command seems to be working well for me. Thank you!

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

2 participants