Hi there
I'm reading through the sample code for the ZMOD4410 2nd Gen, ULP and PBAQ.There is a function called after the read measurement call e.g. zmod4xxx_check_error_event(sensor);
One of the return values that is checked in the switch is ZMOD4XXX_OK - this gives and error. Is this correct?It seems as though this is wrong. Can someone confirm this is correct??
/* Check if measurement is running. */ if (zmod4xxx_status & STATUS_SEQUENCER_RUNNING_MASK) { /* Check if reset during measurement occured. For more information, * read the Programming Manual, section "Error Codes". */ ret = zmod4xxx_check_error_event(sensor); switch (ret) { case ERROR_POR_EVENT: HAL_HandleError(ret, "Reading result: Unexpected sensor reset!"); break; case ZMOD4XXX_OK: HAL_HandleError(ret, "Reading result: Wrong sensor setup!"); break; default: HAL_HandleError(ret, "Reading result: Unknown error!"); break; } }
Thank you!
Hello sir,
Thanks for reaching out Renesas Engineering Community.
It looks that you are right and this probably is a typo mistake. I will also check and report with the sensor team.
If you check the programming manual of ZMOD4410 (https://www.renesas.com/en/document/mas/zmod4410-programming-manual-read-me?r=454426) and check the error coded you will see:
And this error code reports no error.
The specific function zmod4xxx_check_error_event is called to check if any error occurs while measurement process.
If you will check it's body in zmodxxxx.c file
It reads the Power-On Reset register (POR) 0xB7,
1. In case error in I2C read operation occurs it returns ERROR_I2C indicating error in I2C communication.
2. If everything OK it checks the value of POR register (0xB7) to see if Power on reset occurred and if it is true it returns ERROR_POR_EVENT code.
3. If no POR occurs it checks if there is access conflict. In case there are invalid ADC results due to a still running measurement it returns error code ERROR_ACCESS_CONFLICT.
4. If nothing of these occur it returns ZMOD4XXX_OK indicating that no error occurred.
So probably you are right. I will check and report also to sensor team and let you know.
Best Regards,
Irini
Hello Sean,
After doublechecking this with our sensor team. Let me correct my previous answer.
After reading the status then it check if the measurement is still running.
In case the measurement is still running it enters the if condition and goes inside the switch case you are referring to.
Normally, after the proper delay it shouldn't enter this if condition.
Entering this if condition means that the measurement is still running while it shouldn't. Therefore the timing is not correctly implemented if this if condition is entered. Although the sensor reports OK, the measurement setting is not okay.
Hope this makes things clear for you.
Hi - thank you for the clarification. It's good to know it's a timing issue - if it ever occurs.