I tested with a different program. I'm not entirely sure that the problem is in usb serial.
It's still possible that it is somewhere else and we just think it is there.
The same effect as "raw hid" has using a gcc 9.3. Without any line in the code changed. No freeze anymore.
So... IF there is a bug, GCC 9.3 hides it. Maybe it is more smart. Don't know.
Its quite possible, that the bug is inside GCC 5.4 (the one Teensyduino uses) and it produces weird code.
At the moment, I don't know how to find it. Have to think about it.... yesterday I spend another half hour to place "digitalWriteFasts" everywhere in the USB code.
I did not find any problem there.
The effect with DOOM is - the interrupt which is responsible for the SYNC signal gets stalled. The VGA Monitor switches the screen off, then. So it's easyly visible.
The code for this interrupt swicthes of all interrupts (?) <- i fixed that with removing that. But that's still not the reason. The I rised its priority to 0 (<- the highest).
Now.... tell me what that is... it STILL happens (with GCC 5.4)
The interrupt calls the often used function arm_dcache_flush_delete(). The freeze goes away with removing that. Of course the VGA monitor shows a scramnbled picture now. But... here, as we can see it's NOT USB.
Doom does not print much anyway. At least not here, on the start screen. At the first beginning a few lines are printed, but that's all. When the freeze occurs, there are no prints.
I have NO Idea what the problem is. Perhaps, its the same as with your code, Udo: We remove or change something, and the problem occurs somewhere else. Maybe be the USB code. But that does not mean that USB is the problem...
SO... I know less than before. I know that I know nothing... LOL... and I have NO Idea how to find the problem.
But one thing is good: It happens with DOOM, and it is reproducable within seconds to a few minutes.
It's still possible that it is somewhere else and we just think it is there.
The same effect as "raw hid" has using a gcc 9.3. Without any line in the code changed. No freeze anymore.
So... IF there is a bug, GCC 9.3 hides it. Maybe it is more smart. Don't know.
Its quite possible, that the bug is inside GCC 5.4 (the one Teensyduino uses) and it produces weird code.
At the moment, I don't know how to find it. Have to think about it.... yesterday I spend another half hour to place "digitalWriteFasts" everywhere in the USB code.
I did not find any problem there.
The effect with DOOM is - the interrupt which is responsible for the SYNC signal gets stalled. The VGA Monitor switches the screen off, then. So it's easyly visible.
The code for this interrupt swicthes of all interrupts (?) <- i fixed that with removing that. But that's still not the reason. The I rised its priority to 0 (<- the highest).
Now.... tell me what that is... it STILL happens (with GCC 5.4)
The interrupt calls the often used function arm_dcache_flush_delete(). The freeze goes away with removing that. Of course the VGA monitor shows a scramnbled picture now. But... here, as we can see it's NOT USB.
Doom does not print much anyway. At least not here, on the start screen. At the first beginning a few lines are printed, but that's all. When the freeze occurs, there are no prints.
I have NO Idea what the problem is. Perhaps, its the same as with your code, Udo: We remove or change something, and the problem occurs somewhere else. Maybe be the USB code. But that does not mean that USB is the problem...
SO... I know less than before. I know that I know nothing... LOL... and I have NO Idea how to find the problem.
But one thing is good: It happens with DOOM, and it is reproducable within seconds to a few minutes.
Last edited: