Stop trng after generation to save power

[BogdanTheGeek]

We have noticed that after reading a random number from the TRNG, the sleep(Standby) current from our RA2E1 board jumps from ~8uA to ~370uA. I couldn't find any documentation regarding the TRNG, so I am not sure if SGSTART needs to be cleared, but setting both seems to have fixed the issue we were seeing.

Details:

FSP 4.1.0 (I have adapted the PR for the latest commit in master) R7FA2E1A93CFJ#AA0

Code to reproduce:

   uint8_t p = 0;
   while (1)
   {
      (void)RM_TINCYRYPT_PORT_TRNG_Read(&p, sizeof(uint8_t));
      (void)g_lpm0.p_api->lowPowerModeEnter(g_lpm0.p_ctrl);
   }

[michaelthomasj]

@BogdanTheGeek, thank you for pointing this out and suggesting the improvement. There is a time delay associated with re-enabling the TRNG circuit so disabling it after each read would have some performance impact. I think a better approach would be to add a new function RM_TINCYRYPT_PORT_Close() which would disable the TRNG and the Module Stop bit as well. I am assuming the application does some housekeeping before switching to low power mode and the new api can be called in there?

[BogdanTheGeek]

@michaelthomasj Its been quite a while since I looked at this, but from my understanding, the TRNG is started on every Read anyway, and the datasheets seemed to indicate that these bits would be set to 0 in hardware after a result has been produced. I still haven't received any confirmation on what the source of the issue is ( hardware bug, documentation, library implementation ) The code above has fixed our issue with no change to the main code. I would suggest that a 5-10 clock delay to set enable/disable the TRNG is better in most cases then drawing 350 extra uA. Please let me know if an ERATA has been issued about this.

[michaelthomasj]

@michaelthomasj Its been quite a while since I looked at this, but from my understanding, the TRNG is started on every Read anyway, and the datasheets seemed to indicate that these bits would be set to 0 in hardware after a result has been produced. I still haven't received any confirmation on what the source of the issue is ( hardware bug, documentation, library implementation ) The code above has fixed our issue with no change to the main code. I would suggest that a 5-10 clock delay to set enable/disable the TRNG is better in most cases then drawing 350 extra uA. Please let me know if an ERATA has been issued about this.

I just got the timing info and it could be as much as 320 usecs to reenable the circuit as you have done each time.

[michaelthomasj]

@BogdanTheGeek , please take a look at this issue https://github.com/renesas/fsp/pull/328 Similar to yours; that update is more reasonable and it will be in FSP 5.5 scheduled for August. Please close the issue if that solves it for you as well.