#Revision Bug
- Thread starter tarzan
- Start date
Erroneous writes when #revision used for slots 5 through 7.
Pokesfr is a command run during program execution so does not offer a solution, but was used to demonstrate that readrevision is working correctly.
This firmware issue was looked at some time ago but may have over looked the other slots.
Pokesfr is a command run during program execution so does not offer a solution, but was used to demonstrate that readrevision is working correctly.
This firmware issue was looked at some time ago but may have over looked the other slots.
Last edited:
Please disregard “Another bug arises”
Another bug arises. I tried testing this issue with a second EEPROM one at address %000 and another at address %001 on the i2c bus at the same time. Testing was repeated on a separate platform with the same results. I’m attempting to do a round robin of slots gathering revision numbers as each slot is run. Now a new problem arises that “run 0” will not execute when code is running from EEPROM at address %001, it will run from slot 8 instead.
This is all strange behavior because some time ago I managed to do a round robin of slots 0 through 31 without any problems.
Edit: Resolved run issue must remember to use binary not decimal for #slot directives greater than decimal 7 “#slot %00100100” etc. #revision not functional in slots 5 through 11 have not test above 11.
Another bug arises. I tried testing this issue with a second EEPROM one at address %000 and another at address %001 on the i2c bus at the same time. Testing was repeated on a separate platform with the same results. I’m attempting to do a round robin of slots gathering revision numbers as each slot is run. Now a new problem arises that “run 0” will not execute when code is running from EEPROM at address %001, it will run from slot 8 instead.
This is all strange behavior because some time ago I managed to do a round robin of slots 0 through 31 without any problems.
Edit: Resolved run issue must remember to use binary not decimal for #slot directives greater than decimal 7 “#slot %00100100” etc. #revision not functional in slots 5 through 11 have not test above 11.
Last edited:
This is not the same issue as before, and is not a fault with #revision but is related to i2c slots only.
We need to do some more tests as it is very obscure, but it looks like the readrevision internal value may not be refreshed correctly if you happen to run any i2c slot from 'within' another i2c slot. So we guess you probably had success with i2c slot 4 readrevision as it just happens to be the first external slot used, but actually it could be any of the i2c slots.
So this should work
-internal slot (readrevision ok)
-external slot (readrevision ok)
and this should work
-internal slot (readrevision ok)
-external slot (readrevision ok)
-internal slot (readrevision ok)
-external slot (readrevision ok)
but not this
-internal slot (readrevision ok)
-external slot (readrevision ok)
-external slot (readrevision not ok)
-internal slot (readrevision ok)
-external slot (readrevision ok)
The workaround is quite simple and actually the same as before, simply use the 'pokesfr $0E, revision_value' as the first line in your i2c slot. The #revision value in the external EEPROM is actually correct, but is not being copied into the $0E location correctly in this particular situation when the slot starts running, hence the readrevision command (peeksfr of this memory location) does not work as expected.
We need to do some more tests as it is very obscure, but it looks like the readrevision internal value may not be refreshed correctly if you happen to run any i2c slot from 'within' another i2c slot. So we guess you probably had success with i2c slot 4 readrevision as it just happens to be the first external slot used, but actually it could be any of the i2c slots.
So this should work
-internal slot (readrevision ok)
-external slot (readrevision ok)
and this should work
-internal slot (readrevision ok)
-external slot (readrevision ok)
-internal slot (readrevision ok)
-external slot (readrevision ok)
but not this
-internal slot (readrevision ok)
-external slot (readrevision ok)
-external slot (readrevision not ok)
-internal slot (readrevision ok)
-external slot (readrevision ok)
The workaround is quite simple and actually the same as before, simply use the 'pokesfr $0E, revision_value' as the first line in your i2c slot. The #revision value in the external EEPROM is actually correct, but is not being copied into the $0E location correctly in this particular situation when the slot starts running, hence the readrevision command (peeksfr of this memory location) does not work as expected.