This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

TWIS EEPROM Simulator does not send first bit properly.

Hi,

I was exploring TWI master with TWIS Slave example in SDK16.0.0. 

It works for sequential reads in loop-back mode.

Now I connected the simulated eeprom slave to another MCU on another devboard. This MCU does sequential reads on 1024 byte boundaries. So I adjusted the example code's config.h to cater for the MCU's requirements. Everything appears to be working (so I thought). But upon closer inspection, I found out that BIT 7 of the first BYTE sent out by the TWIS is always '0'. For example the actual byte was a 0xFF, I could only see 0x7F being sent out in my logic analyzer. The MCU also receives 0x7F instead of 0xFF. This only happens to the first byte of any sequential read transaction. It does not affect the other succeeding bytes.

The MCU (TW master) follows what is described on Figure 185 of nRF52840 PS v1.1 page 488. Except it reads 1024 bytes after and not just 4.

"Figure 185: A repeated start sequence, where the TWI master writes two bytes followed by reading four bytes from the slave"

The MCU reads 1024 bytes @ address 0x0000, then issues the next Sequential Read command to address 0x0400, then to 0x0800 and so on... until 0xFC00.

All the FIRST BYTES of those addresses get's sent out as 0x7F instead of 0xFF. In short, BIT 7 is always set to '0' on all the first BYTES of any Sequential Read Transaction.

The only thing I modified in eeprom_simulator.c is adding the option to take the Read Address in ees_readBegin. 

Here is my config.h

Take note

define EEPROM_SIM_FLASH_ADDRESS  0x40000

There is nothing specific @ 0x40000. It is a blank area with just 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF....

What the MCU gets when it tries to read it is 0x7F, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF..

It does not matter what address the MCU tries to read. The first BYTE of that Read Address will always be affected and will always loose the first bit to '0'. 

Is this an issue with the EasyDma ?

Best Regards,

Brad

 

  • Hi,

    I tried to reproduce this with the twi_master_with_twis_slave example, but I'm not able to see this issue with your changes added. Are you able to reproduce this with the nRF52840 as master as well, or only with the external MCU? Have you checked the TWI bus with a logic analyzer, to see if 0x7F is actually being transmitted, or if it is the external MCU that does not receive the data properly?

    Best regards,
    Jørgen

  • Hi Jørgen,

    Yes, the problem persists even if the nRF52840 is the master. After I issue an "eeprom erase" via cli, then do an "eeprom read" I get 0x7F 0xFF 0xFF 0xFF...

    Yes, I have seen that 0x7F in my logic analyzer. I am using a saleae logic pro 16 and I enabled the I2C Analyzer. The first bit of the first BYTE is clearly 0.

    I will try with my nRF52832 dev board tomorrow to see if the problem persists.

    I could also upload screen caps from my logic analyzer to show you that this the first bit problem was intentionally 0 and not due to clocking/timing issues.

    B.R.

  • Hi,

    There is no "eeprom erase" command in CLI. Did you mean "eeprom clear", or did your add your own erase command? Can you provide the full project to reproduce this on the nRF52840 DK? As I said, I'm not able to reproduce by adding the code you included in this case.