You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Operating System: Arch linux, up to date CEmu version: latest git Describe your issue:
I have a setup with watchdog timer at 32768Hz with a reload of 1s, set to generate NMI if count reach zero. The watchdog is periodically reset through writing to the restart register (I am writing the restart sequence byte individually), usually in the rst 38h interruption.
Randomly, CEmu execution freeze and console spew a whole load of "Watchdog NMI triggered." without watchdog count being zero (or I think, I had it occur just after the restart load). Please note that setting debugger to open to NMI works, but however stepping doesn't jump to 66h or anything and just generate new NMI without actually advancing in the code step, until randomly jumping to 66h.
It seems that the code executing just before this NMI storm occur is always a seemingly valid port writing (either mapped / or direct).
Trying to monitor port and specifically watchdog port counter 6000 make CEmu crash directly with message
" ../../core/schedule.c :137 : sched_tick: assertion « item->second >= 0 » failed"
EDIT : with a bit more fiddling, I found a more consistent way to reproduce :
running above program, manually increase clock to 48Mhz, step, manually decrement to 6Mhz, step, go back and forth until it trigger NMI (in theory it shouldn't ? Port aren't zero, reading them crash with assertion until jump to rst 66 were you can read them again).
Any logs, error output, screenshot, other comments...?
It may be an issue with what I am doing, as my code is excessively prone to error and weird crash but I wasn't able to reproduce the lock up in HW.
The text was updated successfully, but these errors were encountered:
@TheMachine02 do you happen to know if this was fixed? And for reference, I tracked down the latest commit in your repo when this was reported: TheMachine02/Sorcery@7cf31f4
What's wrong, and with what software version?
Operating System: Arch linux, up to date
CEmu version: latest git
Describe your issue:
I have a setup with watchdog timer at 32768Hz with a reload of 1s, set to generate NMI if count reach zero. The watchdog is periodically reset through writing to the restart register (I am writing the restart sequence byte individually), usually in the rst 38h interruption.
Randomly, CEmu execution freeze and console spew a whole load of "Watchdog NMI triggered." without watchdog count being zero (or I think, I had it occur just after the restart load). Please note that setting debugger to open to NMI works, but however stepping doesn't jump to 66h or anything and just generate new NMI without actually advancing in the code step, until randomly jumping to 66h.
It seems that the code executing just before this NMI storm occur is always a seemingly valid port writing (either mapped / or direct).
Trying to monitor port and specifically watchdog port counter 6000 make CEmu crash directly with message
" ../../core/schedule.c :137 : sched_tick: assertion « item->second >= 0 » failed"
What are the steps to reproduce this issue?
The latest git of Sorcery (https://github.com/TheMachine02/Sorcery/) reproduce this lock up in ~10 min, without touching anything
EDIT : with a bit more fiddling, I found a more consistent way to reproduce :
running above program, manually increase clock to 48Mhz, step, manually decrement to 6Mhz, step, go back and forth until it trigger NMI (in theory it shouldn't ? Port aren't zero, reading them crash with assertion until jump to rst 66 were you can read them again).
Any logs, error output, screenshot, other comments...?
It may be an issue with what I am doing, as my code is excessively prone to error and weird crash but I wasn't able to reproduce the lock up in HW.
The text was updated successfully, but these errors were encountered: