Interacting with HE910 via SPI

16 thoughts on “Interacting with HE910 via SPI

  1. I’m trying to send AT commands to the HE910 module via the SPI port, but I’m not having any luck getting any output back (only NULLs are returned on the MISO line).


    The message I’m sending is a simple ‘AT’ and I expect a response back (like an ‘OK’).


    This is what my header+payload looks like:


    4 byte header: 0x00, 0x00, 0x10, 0x18 (currrent data size field = 0x18 = 24 bits = 3 characters)


    3 byte payload: 0x41, 0x54, 0x0D ( = ATr)


     2041 NULL characters (0x00) to fill remainder of the payload.


    After sending these characters I simply continue clocking the SPI clock to see the response, but nothing appears on the MISO line. In addition, the SRDY line never goes low again after I initially set MRDY high (I’ve tried lowering and raising MRDY but it had no effect on SRDY). So I’m not sure why the module isn’t sending any characters back, or of it’s having problems parsing the data on the MOSI.


    I’ve also tried sending ATrn, ATn and just AT and had the same result. 


    Thanks for any help.

  2. Hi,


    I am having a similar issue as Shakeeb. I was wondering if you would have any other extra documentation about the SPI comunication, besides a “HE910 SPI Port Application Note” from 2011 I found.


    Would you have a C sample code available too?


    Thanks in advance. 

    1. Q) I had a question regarding the SPI Serial Protocol format. The documentation isn’t very clear and
      I’m confused as to what the ‘Next Data Size’ and ‘Current Data Size’ fields refer to.
      The documentation also states that the payload has a fixed length of 2044 bytes.
      Does this mean that every message must contain a 4 byte header + 2044 byte payload = 2048 bytes?
      It would be great if you could provide me with an example.
      For instance, what would the complete output look like (in hex for header + payload) for
      this command: at#sd=1,0,20000,

      A) SPI send a whole frame (4+2044 bytes )every time it needs to send data.
      The first 4 Bytes compose an header where bit are mapped as follow:

      bit 31 maps DTR/DSR status
      bit 30 maps CTS/RTS status
      bit 29 maps DCD     status
      bit 28 maps RING    status
      bits 27-18 are the dimension of next packet ( if any, otherwise 0); this is needed by SPI protocol
      to know if MTDY has to be kept high or can be set to L.
      bit 12 is H
      bits 11-0 are the dimension of current data packet.
      RES are reserved.

      Attached a sample for the commadn AT#SD …


       RenameSPI.txt to SPI.xlsx.

  3. Thanks for your reply Cosmin,


    I’ve tried sending a message as described in your example (see header+payload data from first post). The problem now is the SRDY signal goes low right after the HE910 receives the first character of the header on the MOSI line, and never goes high again (MRDY is high the whole time), so I never get a chance to send out the rest of the header and the payload.


    If I lower MRDY and then raise it, SRDY goes high again and the cycle repeats. I’m not able to send out an entire header+payload in one message (I can only send the first character of the header). 


    Do you know why the SRDY line won’t return high? Should I keep sending data even if the SRDY line is low? Are the MRDY/SRDY signals active high or active low?

    1. Hi Shakeeb,


      I think I mistake to writ emy excell file I’m sorry.


      Tha header bytes are read from but 0 to bit 31 as in the attached file. 

      Please try the same and let’s know.


  4. Luca,


    I tried with your example but the SRDY signal still goes low immediately after receiving the first character. I have tried with MSB first, LSB first, and various clock phase/polarity settings since there is so much contradictory information. In fact, I’ve tried sending every character from 0x00 all the way to 0xFF as the first byte of the header and the SRDY signal simply does not stay high.

    Are these are the right settings? CPHA=0, CPOL=0, 8bit MSB.


    I’m sorry but the documentation is simply awful and I’ve wasted many hours trying to get this interface to work.


    The manual states that the miso/mosi pins are shared with the tx/rx pins for the aux_uart. How does the module know which one to expect? Is there some setting that must be set to turn on the SPI? Or is it as simple as just connecting to the proper pins? 


    Secondly, can you please provide me with some actual CODE (i.e. the code you used to test the SPI) so I can verify with it myself?



  5. Hey Luca,


    I set it, rebooted the module and checked with at#portcfg? to make sure it was set, but the behavior persists (SRDY -> low after receiving any character, basically it sees 8 clock edges and immediately drops SRDY). 

    I’m working with the EVK2 development kit.
    1. So, is there a solution or can I assume the SPI interface on this module is broken?


      We were planning on using this module in of our new products, we already have a customer who would like to see a functioning prototype before purchasing a thousand of our units. If the SPI interface does not work then we will simply look elsewhere for a different module to integrate into our product.



  6. Luca,


    I’m attaching a screen capture of what we are experiencing – as you can see, our SRDY drops as soon as the first character (0xAA in this example) is sent. Your screen capture shows that the signal stays high, so we are not experiencing the same thing. Do we have a defective unit?

    Logic low is 0V and logic high is ~1.8V.
      1. Luca, 


        Yes, D13 is jumpered with E13 for 1V8_SEL.


        AT+CGMR reports 12.00.001-B015 but I’ve read that 12.00.003 is the latest. Can you attach it please (I don’t have access to the download zone).

          1. We updated the firmware and now we just have more problems:


            1)  We see repeated periodic messages "+PACSP0" in the UART interface. How can I turn this off? I’m assuming it’s being sent to the SPI interface as well. This wasn’t a problem on the old firmware.


            2) The SRDY signal now goes high by itself upon reboot (likely due to the reason I mentioned above). I’m assuming the procedure to receive data is to set MRDY high and send 0x00 characters while clocking the SPI. However, this causes the module to REBOOT itself. In fact, the behavior from the previous firmware has changed so that instead of making SRDY low, it REBOOTS the module instead.


            3) Can you please provide a CODE example for messages being exchanged across the SPI? Don’t worry about the platform/processor/language, we’ll try to convert it to match our hardware (MSP430 processor).

          2. Hi Shakeeb,


            you are using a AT&T SIM I suppose so you get the PACSP0 unsolicited message at power on.


            So SRDY go high to indicate a need to send data …