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:
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
, andseconds
specified in the initialarm
orrearm
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.