Energy Harvesting/VCC issue on the NFC04A1...

[damien_lobb]

Hello,

I have an issue with the energy harvesting functionality on the NFC04A1, which I believe probably has a very simple solution. If the reader is kept on the tag then EH is happening and working fine, then if i take the reader away from the tag, there is no power, as expected.

However, if I then put the reader to the tag again, although I get 3.3V at the jumper, none of my code will work. E.G. NFC04A1_NFCTAG_GetVCC_Dyn() returns an error indefinitely.

I can reset the program and its fine again, until it loses VCC again. This is a pain, as i find that if I put the jumper on constant VCC, the tag field can drop out randomly for a millisecond or so. If this happens with EH, it completely ruins the program.

I imagine I cant be the only one who has noticed this, so I'm sure there is a simple fix. I imagine that fix already happens in my init function, but it would be handy to pinpoint exactly the point that it does, rather than run a lot of needless code.

Thanks

Damien

[JL. Lebon]

​Hello,

Thank you for using ST25DV!

What is the position of ST1 jumper when your problem occurs ? Is it on 3.3V or on EH ? Sorry it is not completely clear for me from your explanation.

In other words, are you powering the ST25DV from EH or from the 3.3v signal ?

Best regards.

JL.

[damien_lobb]

It is when I am powering the board from the EH supply. ​If it is just from 3.3V there is no issue. However, I was under the impression that it was able to power the chip with EH when available. If that loses power however, I'm not able to do anything in the program until I restart.

[damien_lobb]

I've gone through the debugging, and it appears to fails in the BSP_I2C1_ReadReg16() function. It returns BSP_ERROR_PERIPH_FAILURE, so it seems its the I2C failing after the board loses power.

[damien_lobb]

I have tried using DeInit functions for the tag and for I2C. I reinitialise the I2C, which returns without error, but when trying to reinitialise the tag it fails at the same function with the error BSP_ERROR_PERIPH_FAILURE. The only way I can seem to get around it, is to completely restart the chip using NVIC_SystemReset().

[damien_lobb]

Just noticed its actually in the function HAL_I2C_Mem_Write() where there is a timeout and the function returns HAL_BUSY.

[damien_lobb]

I believe I have found the problem. When the power is removed during an I2C function, the SDA line is pulled low and never goes high again, as its still waiting on data.

"Remember that EEPROMs don't have reset pin. If the MCU is reset/restart while reading data (says 0x00 data), the MCU will restart with SDA tied low by the EEPROM. Run 9 stop bits to clear the bus..."

Now I just need to work out how to send 9 stop bits...

I imagine this is a common issue so is there a built in function in the HAL_I2C driver?

[JL. Lebon]

Dear Damien,

The 9 stop procedure is not for ST25DV product, but for an older product (M24LR). So it won't have any effect on ST25DV.

Anyway, I don't think your problem is coming from the ST25DV.

Inside ST25DV, there is a timeout mechanism to prevent SDA signal lock. When SCL is not moving for at least 30ms, SDA is automatically released. So the ST25DV will not tie low the SDA line for more than 30ms if the MCU stops reading data in the middle of a transaction.

Another point to consider is that ST25DV is, in your case, powered only by the RF reader, either on RF side or on VCC side through EH. This means that in case of RF field drop, the device is no more powered, and thus is reset. So when you remove the RF field (and if VCC is connected to EH), the device is reset and I2C interface is restarted in a clean state when RF fields comes back.

What I have seen on me side, setting ST1 on EH as you do is:

- set RF field: EH output is 3.3V, I2C communication is working -> Remove RF field -> Set RF field again: EH=3.3V, I2C communication is OK.

- set RF field: EH output is 3.3V, I2C communication is working -> Remove RF field -> I2C read: failing (expected) -> Set RF fields again: EH=3.3V, I2C read: failing (not expected!).

So it looks like the I2C read done when the RF field is not present is creating the failing condition when RF field is back. When RF field is not present, the ST25DV is not powered, so can't create the issue.

Putting a scope on SCA/SCL in failing conditions shows that both lines are tied low.

My guess is that something is going wrong in the MCU FW when trying to access the ST25DV and the device is not present (i.e. not powered).

Can you please give me more detail on the FW you are using (is it based on NFC04A1 HAL?, which version ?) and on the Nucleo board you are using ?

Best regards,

JL.

[damien_lobb]

Thank you for the reply.

Firstly, I am using the F401RE board and have developed my code around the NDEF_URI project in the STM32CubeExpansion_NFC4_V1.3.0 FW.

For testing purposes, I have been moving the jumper to VCC, and taking it out when in the middle of a process, and then putting it back (mimicking the EH issue but guaranteeing power afterwards.)

What I am seeing;

1. VCC is lost during a I2C read/write - and that function fails.
2. SDA/SCL are both tied low.
3. VCC comes back to the ST25DV
4. Run the DeInit I2C function, SCL/SDA both go high
5. Try to reinitialise I2C, but as soon as the init function runs, SDA/SCL turn low again.
6. When reinitialising the tag, NfcType5_TT5Init() function fails with NDEF_ERROR and I get a HAL_I2C_ERROR_TIMEOUT when I2C tries to write.

The Init code runs successfully in code (As in there isn't an error) but as soon as it tries to read/write it fails.

For the record I also see similar problems on the other projects. On the EH example if it loses the RF field, the button click works about 10% of the time.

[damien_lobb · Accepted solution]

I have found a solution to the issue.

While monitoring the registers I noticed that after the setting the SWRST bit, the reinitialisation wasn't setting the CR2 register properly, and as a result, was setting the speed of I2C to 0. Now, when the tag loses power during a read/write, it isn't sending a stop bit, which is where the issue spans from. I'm sure there is a better way around this, which I will continue to investigate, but right now, I do this;

1. Catch the loss of power and retry until a timeout of 5 seconds is reached.
2. Set and clear the SWRST bit.
3. Deinitialise I2C.
4. Initialise I2C.

Note that doing the Deinitialise function before SWRST will not work.

As I said though, I imagine there must be a better way of sorting this issue. When the tag loses power during a read/write, it doesn't send a stop bit. Rather than going through the above fix, surely it can just reset the CR1 register (and possibly SR) ?

Thanks

Damien