Start a new topic

rept returns "0xFD 0xFF 0xFF 0xFF"

 Hi again,


when trying to read data back from EEPROM, where I had written some with "wept 12,4", the corresponding "rept 12,4" returns the four bytes (in hex) "FD FF FF FF". That looks like a standard response, but return code 0xFD is not defined, nor is anything else but the EEPROM data as response from the rept command.

rept commands without a preceeding wept will return the data bytes as expected.


All this is done via UART from an Arduino, by the way.


I suppose this is some timing issue with the wept command. Is there a defined time to wait before executing the next command after a wept?


it seems more like you read from byte position 12 four bytes.  they were FD FF FF FF

rept pos,count  - rept reads from position, count number of bytes


an uninitialized flash byte will be FF

wept pos,count

so wept 12,4 is to store 4 bytes at byte position 12

- the wept command replies with  FE FF FF FF to signal it is ready to receive.

- wait for ready before sending then send count bytes.

wept will remain in receive loop until all count bytes are received.


Hi Patrick, Yes, all right so, I am doing just that. ;-) The data I wrote are the 4 bytes of the number 1234567 in low-endian format. In the meantime I found out that a delay(100) after the wept is sufficient for the rest to result in the expected data. Only if I will send the rept immediately upon the return from the wept command the FD FF FF FF pattern can be observed. No big issue, but I found it interesting that there seem to be more return codes than are published in the wiki.
"rest" = "rept".... Sorry, auto completion does funny things.

0xFE is documented, I am assuming that something else is involved in obtaining a 0xFD

It is not the 100ms that you need to be waiting for but the FE FF FF FF sequence.


What will the eeprom byte values be when it is in the middle of being flashed?

This too could be a source of uninitialized data. (FFs)

Believe me, the EEPROM has been used already - no 0xFF in there. I seem not to have made it clear, so here is the sequence : 01. wept 12,4 02. (wait for FE FF FF FF) 03. Send 4 bytes for 1234567 04. rept 12,4 05. Read 4 returning bytes: FD FF FF FF! If I add a step 03a. as delay(100), the result of step 05. will be the bytes for 1234567 again. To be repeated as often as you like.

Okay.  Clear.

So, Good news - there is an 0xFD return code. (we'z not goin' krazy)

Bad news, not in the Nextion Instruction Set yet,

 - and I do not read Chinese, so waiting for a translation


Okay Michael


0xFD 0XFF 0XFF 0XFF is return code when data transfer is a success.

You will want to modify your code to capture this success return code and

then issue your repo

Nextion Instruction Set now updated to include 0xFD


1 person likes this
Thank you for clarification :)
Login or Signup to post a comment