Hi,

another problem, this time with EEPROM. I try to read it by sending"RDEP" command.

I send exactly what is mentioned in manual "RDEP" and then 0x00, 0x00, 0x00, 0x20 (I want to read 32 bytes starting from address 0x0000).

No matter what data length I specify (on these last two bytes) the module always replies with 2 bytes !!!!

What is going on there ????

Jacek

seems same problem as before: your program sent a terminal char after command "RDEP" (usually value 0), it will cause the display to stop sending out the rest of data that you want to read out.

Hey, sorry but all the time total misunderstanding. My "terminal" (microcontroller) sends EXACTLY what I want. The manual says that after R, D, E, P (ASCII codes) I should send 2bytes of address and two bytes of data length.

So to hell I SEND exactly these 8 bytes as mentioned in my previous thread ! Or maybe EEPROM start address is not 0x00:00. If not why it is not mentioned where to hell is this EEPROM located ??????

Where do I have to take this information from ? Maybe someone could draw CLEAR memory map (for example exact addresses of flash segments starts).

I assume that if nothing is mentioned that I can start EEPROM from address 00:00.... I have tried another ones. Of course it doesn't work at all - the module replies always with two bytes.

Ok if this is another feature in this module which doesn't work I have to apply external EEPROM. So please stop advertising that in module I have nearly 1k bytes of EEPROM for usage.

Jacek

We don't know what wrong in your application, our displays have been used on many industrial machines world wide, where touch panel were used (don't know if they used internal EEPROM).
If you can, please try our Arduino lib on an Arduino board, and see what happened.
Due to we can't see your code, then it's hard to us to address the problem you have.

Hi,

my code is very simple ! I use UART as mentioned before, so other commands with printing text, drawing some graphics what I have checked work well.

I SIMPLY send these 8 bytes as mentioned in manual and mentioned in above thread. Just byte by byte, and then I wait for reply from module (similarly I do it with "RPNXY"

and then after touching screen I receive a train of bytes). In the case of "RDEP" I receive ONLY two bytes (0xFF because EEPROM is erased), no matter what data length

I specify. So there must be a bug or manual has the errors.

I will try to upgrade to version 4.3 (if it works....) and we will see what happens.

Jacek

To simplify your order, please use a USB->UART adapter and coolterm software to test the display on computer, here is our test:

1)use "WREP" to write 1,2,3,4,5 to EEPROM from address 0

2)use "RDEP" to read 16 bytes of data from EEPROM from address 0

The result is here:

We don't know what wrong in your program acctually, you probably sent extra bytes of data to stop the display sending back the data or you didn't use interrupt on UART which cause you loss data received.

Gentlemen please, I use UARTs since YEARS. The method the most convenient for me in such situation is to send a command (no matter where and how) and then to wait in a loop for a flag.

This flag is set by interrupt service routine when all sent bytes are received. I recognize the end of transmission by a timeout, in 9600 let's say 50ms.

It works perfectly in all other applications. Here it doesn't matter in fact if I use interrupt or not because I observe module's Tx pin on oscilloscope, so I clearly see how module reacts.

BTW, upgrading to version 4.3V caused that even these 2 bytes are not sent. The module doesn't respond at all !

Aha, I send EXACTLY the same sequence as specified above..... but there is one small difference : I do not write anything first. I just want to read memory and then decide what to do next.

But I should be able to read it at any time I need, shouldn't I ?

brgds

Jacek

To simply the problem, please take a screenshot on coolterm to let us see what you got, use our email: question@digole.com.

Also, let us know how did you upgrade the firmware on the display? step by step please, because we can't duplicate the problem you have.

Dear Service,

1. I have upgraded FM exactly the way as it is described on your website. It works very well. No problem with it.

2. Regarding UART I have made deeper investigation - it has occured that new MCU I have applied here accidentally sends at the end of finished transmission one extra bit

which is recognized by module as next start bit. I had to change the way of closing the transmission so now detailed analysis on the oscilloscope shows that transmission

ends exactly as it should. Nothing extra is produced.

3. Taking above into account I can say that RPNXYW works ! Also RDEP, however erased EEPROM sends 0x00 instead of 0xFF. Looks a bit strange. But OK, no problem with it.

4. The problem with longer string still exists, but for me it is no problem to send another string in the same line.

It looks that most terrible problems were solved so I continue to develop further software parts.

Thanks a lot for your help so far (especially this example with CoolTerm was very helpful) !!

Best regards

Jacek

Try to test our display by using coolterm, use like "TT123456789012345678901234567890" to see if the display show whole string on the screen if the string length over 22 bytes, the terminate char for "TT" command is value 0 (0x00), not ascii "0".