CyU3PPibRegisterCallback and CYU3P_GPIF_ERR_INVALID_STATE errors

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
NiMa_2741046
Level 1
Level 1

Hello,

in my CX3-based application I enabled the 'PIB interrupt' callback, by registering my CyU3PPibIntrCb_t-compliant function with the CyU3PPibRegisterCallback API: I don't need this for any purpose apart checking for unexpected conditions while I'm in a debug phase for the entire application.

Surprisingly I'm having my callback called many times during apparently normal operation, with cbType == CYU3P_PIB_INTR_ERROR and CYU3P_GET_GPIF_ERROR_TYPE(cbArg) == CYU3P_GPIF_ERR_INVALID_STATE.

Even if I'm not sure that it is legal to do so, in those circumstances I'm trying to understand which GPIF SM state is considered 'invalid', by calling the CyU3PGpifGetSMState from inside the callback. According to that procedure the states that seem to trigger the error are: CX3_IDLE_SCK0/1, CX3_WAIT_FOR_FRAME_START_SCK0/1, CX3_PARTIAL_BUFFER_IN_SCK0/1 and undocumented states 131 and 132.

Since I'm working on the CX3 device, I'm using the 'fixed'function' GPIF configuration that results from the call to CyU3PMipicsiGpifLoad(CY_U3P_MIPICSI_BUS_24, buffer_size).

Is the described behavior normal/expected ? If not, what could be causing the triggering of those errors ?

Please note that my application is currently a bit peculiar because I'm programming a custom D-PHY/CSI-2 sensor for image frames composed of a single line: as a result I'm currently keeping the line/frame rate quite low (compared to what supported by the sensor HW) in order to be able, on the CX3 side, to keep up with the corresponding interrupt rate.

Thanks in advance and best regards, Nicola.

0 Likes
0 Replies