search

mikechambers84 / STM8-Emulator

An STM8 microcontroller emulator and hardware design simulator.
GNU General Public License v3.0
23 stars 2 forks source link

STM8S003F3 device doesn't work - throws access violation #9

Open basilhussain opened 2 years ago

basilhussain commented 2 years ago

When attempting to use STM8S003F3 device emulation (with -cpu STM8S003F3 argument), an exception is thrown with an access violation: Exception thrown: write access violation. IO was 0x11101120147A6D1.

It occurs in the first line of uart3_init():

IO[regaddr[UART3_SR] - io_start] = 0xC0;

As far as I can tell, it is because the STM8S003 does not (and should not) have a UART3, and thus the register addresses in regaddr[] are not initialised. The default value for all uninitialised regaddr[] entries appears to be 0xFFFFFFFF, so because IO[] is only 0x800 in size, and io_start equals 0x5000, the above line is of course trying to write far, far beyond the end of the IO[] array.

This leads me to assume the STM8S003 implementation is actually unfinished, as I can't imagine how this bug has otherwise gone unnoticed. Perhaps until it is, it should not be listed as a supported device?

I'm thinking the solution may need to be some kind of flag system to signify that a certain device does not have one or more peripherals.

mikechambers84 commented 2 years ago

Odd, I've used the STM8S003F3 a number of times. I've tested this out, and I'm still not getting getting any exceptions. The emulator runs for me.

You're correct that the 003 doesn't have a UART3 though. And yes, I used a flag system for peripherals in my PC emulator, that would make sense here too! I have a few days off work, I'll get something done for that!

basilhussain commented 2 years ago

Maybe it has something to do with how it is compiled. Perhaps the access violation is only thrown when compiled in Debug mode? Or maybe it's an x64 thing? Or both combined? Debug x64 mode is what I had compiled it in when I got the exception.

mikechambers84 commented 2 years ago

That makes sense, yes! I was using x86.

In 32-bit mode, 0xFFFFFFFF would be the same as -1, so it wouldn't be out of bounds.

basilhussain commented 2 years ago

Hmm, but array indices are treated as unsigned, and 0x5000 is being subtracted from 0xFFFFFFFF, so I don't understand how that out-of-bounds access (to index 0xFFFFAFFF of an array whose last element is 0x7FF) happens to be benign, even if it doesn't throw an access violation.

Maybe on 64-bit Windows there are more strict memory-access checks.

mikechambers84 commented 2 years ago

You're correct. I literally just got out of bed, I need my coffee. In any case, I'll fix it.