Unexpected ASR-1 reply to SPI Zero Sync


I am receiving an unexpected reply from the ASR-1 when the MCU sends a Zero Sync on SPI. After each interrupt from the ASR-1, the MCU clocks out the Zero Sync on MOSI (0x30 0x00 0x00 0x00 0x00 0x30) and 0xaa 0xaa 0xaa 0xaa 0xaa 0xaa is clocked in on MISO. Can anyone explain this please?

I was expecting to see 0x30 0x00 0x00 0x00 0x00 0x30 or similar on MISO.

The SPI is setup for little endian, clock low during idle, data set on clock rising edge. Clock frequency is ~500kHz.


Hi Marshall!

We’ve seen this pop up before once in a while. I’m researching this with our firmware folks today to see if I can come up with a better answer for you. Can you try to add a small delay (few hundred milliseconds) before you start clocking in from MISO and see if you get the right bytes? That will help us figure out what’s going on.

You’re correct that you should get the zero sync bytes back from the ASR-1, and you usually do, but sometimes I’ve seen a string of 0xAA pop up and I don’t have an exact answer for you right now.

Let me know if that changes anything for you, thanks!



Also, do you have specific code that’s doing this or are you seeing this with afLib? If you have custom code, do you mind sharing it?





Thanks for getting back to me. I’ve attached a couple of scope shots that may help.
Ch1 (Yellow) SPI Clock
Ch2 (Green) MOSI
Ch3 (Blue) MISO
Ch4 (Red) Interrupt from ASR-1

When you suggested adding a few hundred millisecond delay before I start clocking in MISO, do you mean a delay between the interrupt from ASR-1 and the beginning of the clock? Right now there is a 60usec delay but I can increase that to a few hundred msec.

It is specific code written for a custom PCB. I can send snippets of the code but I thought the scope traces may help more. I ordered an Arduino Teensy and was planning to use it with your afLib for comparison when it arrives.

I get an interrupt from the ASR-1 about every 0.5sec. After each interrupt, my board sends the Zero Sync and the ASR-1 responds with the 0xaa, every time - very repeatable.



Good info, thanks! Let me bounce this off the firmware guys and I’ll reply back soon.




So is there any chance that you’re getting 0x55 instead of 0xAA?

If you try to clock out more characters than we have in the ASR-1 transmit buffer, you’ll get 0x55.

We will send 0xAA if the master starts a transfer that the ASR-1 isn’t ready for, but we don’t send an interrupt to the master unless we’re ready to communicate, so this, in theory, “shouldn’t happen” but you know how often “can’t happen” errors rear their heads in this line of work. :smile:

I’m gonna see if I can come up with a small test case for this. With afLib I don’t see this unless I’m looking at something different.



One thing to try, if you’re seeing 0.5s interrupts from the ASR-1, this is happening when you first power on the ASR-1, then, isn’t it?

When you see interrupts from the ASR-1 after power on, reset it by bringing the RST line low for about 200-250ms then high again, then try your zero sync.



Also, if this is a custom PCB, is your ASR-1 a module off of a reel, or are you using a Modulo? There’s new firmware out as of a month or two ago, which Modulo boards should get automatically, but ASR-1 modules off the reel will come with older firmware until they come online to get updated, so this may be an older firmware issue that’s since been fixed. Can you connect to the UART pins on the ASR and let me know what is says when you reset it? (38.4k bps, it’ll spit out a copyright notice, it’s associationID and deviceID, and three firmware versions) – the firmware version(s) would be useful to know.





Here is an update based on your suggestions:

  1. Per one of your earliest suggestions, I added >350msec after the ASR-1 interrupt to the beginning of the SPI clock. (Recall is was 60usec.) It didn’t make a difference so I changed it back. I thought this might fix it too once you said the ASR-1 sends 0xaa if the master starts a transfer the ASR-1 is not ready for (even though the ASR-1 sent the interrupt).
  2. I am seeing 0xaa for all six bytes on the MISO. I reconfirmed it is not 0x55. I am only clocking out 6 bytes for the Zero Sync.
  3. I am using a Modulo and not the ASR-1 off the reel. I have not connected the UART yet to find the firmware revision. I don’t know if this helps but the profile editor shows SW Version v13866 for this Modulo.
  4. About 1msec after power up, my board asserts a reset to the ASR-1 for 500msec. I can also assert a 500msec reset later (after the ASR-1 is sending the interrupts) by restarting the debugger for my code. Even after these resets, I still get the 0xaa bytes on MISO.


Wow, okay. That about shoots down my suggestions. :smile:
Do get the firmware version(s) if you can, or if you can email or PM me your Afero account name I can look it up on this end. If it’s a Modulo you should have the latest firmware (its OTAed automatically when you have the device online, probably did it weeks ago).

Other than that, let me hit up the firmware guys for more information.





I was able to capture the info over the UART on power up:

Hope this helps.


That does help. You’re on the latest firmware, so the old firmware bug I was thinking about unfortunately doesn’t apply to you. :smile:

Let me go back to the mountain and I’ll get back to you.




Still not having any success replicating this, still thinking about it though. Sorry for the delay!


If you can (when you can), please PM me with some details about your setup. Try as I might, I can’t get an ASR-1 to give me 0xAA as a sync response no matter what I do do it - I’m even trying to send it a zero sync before I get any interrupts, and I still get back a valid response. If you can share a little bit about your setup and code (either PM me here of email me at jgeorge at afero.io) I can see what else we can do to help.

Sorry I don’t have anything more useful,



I am currently comparing a Teensy connected to a Modulo running the Blink profile to my setup also running Blink. The Teensy is running correctly but I am not seeing any differences in the scope traces (CLK & MOSI) other than the clock frequency. But MISO for my setup is still 0xAA. I will look into it more and if I can’t find anything, I can send you more information or it may be easier to send you my setup. I suspect you could put my setup on your debugger and tell right away what is happening; and not have to struggle duplicating it. But first want to make sure I am not doing something wrong so I won’t waste your time.



FWIW you’re not wasting my time, that’s my job - if you’re trying to use our platform I’m here to make it easier on you if I can!

Feel free to drop me an email directly with more info on your setup and we can help if you have any troubles figuring it out. But if you’re seeing the proper response from the ASR-1 on a teensy then there should be something we can see that would be the difference.

Let me know if we can help in any way!