Strange Behavior Attn Pin: Pin goes high before response to arm

Noticing weird behavior with notecard/ notecarrier (Notecarrier B, FW: 1.5.3.12460). Attn pin is going high for 0.3ms after arming it on a file. My FW requests a note.get on the file which then receives this response: {“err”:“no notes available in queue {note-noexist}”}. Also nothing has been added to that specific file so the behavior makes sense, but why does it go high? Probably worth mentioning that attn pin goes high before transmitting the success response ("{}/r/n") from the card attn command. Serial data pictured below.
Top is the attn pin, middle is Tx from note card, bottom is Tx from MCU:
image

I have included a work around in MCU FW to not check the attn pin until success response is received, but worth mentioning to devs

Hi Abenezer,

Could you try substituting the word “rearm” instead of “arm”:

{"req":"card.attn","mode":"rearm,files,..."...}

This should avoid the high glitch on the attn pin when the Notecard processes the request.

thanks
Sean

I also recommend updating the Notecard firmware to 1.5.5 - our newest developer release.

1.5.5 fixes some important bugs in earlier firmware.

thanks
Sean

Hello @abar2437,

Thanks for joining the forums! This is an excellent question, and thank you for including the scope capture.

If I am understanding correctly…

  • the bottom line, ending in “}”, “\n” is the tail end of the original {"req":"card.attn", "mode":"arm", ....
  • the top line shows the response from the Notecard on the ATTN pin
  • the middle line shows the response from the Notecard on the UART.

We can see from your scope capture that the Notecard ATTN pin is already in the ARMED position (held low) when you sent the request to ARM. As a result, it disarms and rearms the ATTN pin.

For circumstances nearly identical to yours, "mode":"rearm" was added to the card.attn API in version 1.5.3.

To eliminate your workaround, I believe you can simply change the mode from arm to rearm. It is also worth noting, that the ATTN pin does NOT need to be “armed” in order to “rearm” it.

Please give this a try and let us know how it works.

Cheers,
Zak

Hello Zak,
Thank you. Can ask you about the resetting note put under the rearm API?

"rearm" (Added in v1.5.3)

Will arm ATTN if not already armed. Otherwise, resets the values of mode , files , and seconds specified in the initial arm or rearm request (idempotent).

Can you clarify in what situations it would reset values? and what exactly does a reset mean in this case (is it disarming)? What does rearming with a specified file do?

Hi @abar2437,

I believe I understand your confusion. The ATTN interrupt is a “latching” interrupt, and it does not automatically reset itself.

Therefore, when you arm or rearm the ATTN pin on a file, you are setting a file-specific trigger. Once the file receives an update, the trigger is tripped, and it will not fire again until you reestablish it.

In the case of a time based trigger (which I don’t believe you are using), once a timer expires it would trip the trigger. In this case, rearm would reset the timer associated with the timeout value without ever tripping the ATTN pin.

In your specific case, let’s assume you are currently configuring the interrupt using…

{"req":"card.attn","mode":"arm,files","files":["myfile.qo"]}

You will instead use:

{"req":"card.attn","mode":"rearm,files","files":["myfile.qo"]}

After your interrupt handler has fired, then you will need to configure the ATTN pin again using either arm or rearm. To get the behavior I think you are looking for, you will want to use the the same call (as the original) to rearm to reset the interrupt.

1 Like