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

twiboot timeout issue #6

Open
MS71 opened this issue Aug 19, 2021 · 1 comment
Open

twiboot timeout issue #6

MS71 opened this issue Aug 19, 2021 · 1 comment

Comments

@MS71
Copy link

MS71 commented Aug 19, 2021

Hi,
i ported twiboot to my Tiny84 target.
So far, it is working. I am able to download the code and start a small demo application via the I2C command.

Unfortunately, it is not starting without any I2C communication (timeout).
Any hint?

For debugging, i added some fast LED toggling just before jump_to_app();
The problem, is, that my app code is just not working, when it is started by timeout.

Additional, i think there is a concept error with the appvect_save variable.
I think, the appvect_save & rstvect_save are initialized with the wrong value in main.
When I check/compare without writing it, then i get a mismatch with the original code.

I think, it should be:
rstvect_save[0] = buf[APPVECT_PAGE_OFFSET];
rstvect_save[1] = buf[APPVECT_PAGE_OFFSET + 1];
appvect_save[0] = ?;
appvect_save[1] = ?;

I added a simple CRC16 checksum query. This is very useful doing a quick code compare without read the entire flash to the master.

Later, i like to add support for the AT Tiny841 too. This device has a different I2C slave implementation.

Shall i provide a pull request for this?

Maik

@orempel
Copy link
Owner

orempel commented Aug 19, 2021

Moin,
without seeing your code changes I would guess that the HW timer is not running correctly and thus never setting "cmd = CMD_BOOT_APPLICATION" in TIMER0_OVF_vect. Might be an overflow in the TIMER_MSEC2TICKS / TIMER_MSEC2IRQCNT calculation if you have changed the default values for those.

There is no concept error in the virtual boot handling:
Verify is only possible after flashing, since the RESET vector and the "app" vector (EE_RDY by default) are patched while writing:

  • the "app" vector is patched to store the user application entry address (taken from the RESET vector of the hex file you are flashing)
  • the RESET vector is patched to store the twiboot entry address (eg. 0x1C00)

This is required to start twiboot before the user application without having a bootloader section. It implies that the "app" vector must never be used by the application since it is used by twiboot.

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