[Solved] Understanding MISO Line with ATWINC1500

[JPMartinez]

Hello,
 

I've been trying for a while to integrate a ATWINC1500-MR210BP1954 (from Digi-Key ATWINC1500-MR210PB1954)  module in my custom board with a STM32L151. Project is done with STM32Cube environment. For debugging purposes I am only trying a simple code, sending a command with SPI and checking that response is the good one.

The problem is that I am not getting the right SPI response in my custom board but when I use a NUCLEO-L152 evaluation board with a ATWINC1500 module (same one),  I get the correct response.

 
SPI config is the following : CPOL = 0, CPHA = 0, 8bits, MSB First, 1 MBit/s (using MSI RC with prescaler 2). This settings were made according to the module data sheet p. 21 https://ww1.microchip.com/downloads/en/DeviceDoc/70005304D.pdf

Code in main.c is the same for my custom board and for the Nucleo except for the pin numbers for CS, RST and Enable.

This SPI message is the same as p121 : https://ww1.microchip.com/downloads/en/DeviceDoc/ATWINC15x0-Wi-Fi-Network-Controller-Software-Design-Guide-DS00002389D.pdf

 
To wake up the chip the MCU sends : 0xC4 0x80 0x01 0x00

I get the following responses :

NUCLEO+Module(alone) : 0x00 0xC4 0x00 0xF3 0x01 0x00 (yes, good reponse)

ATWINC in my custom board : 0x01 0x88 0x06 0x00 0x00 0x00

 

I checked the signal in my oscilloscope.

In both cases the MCU is transmitting correctly in the MOSI line.

I found what, I think, is a problem in the MSIO line in my custom board :

" alt="" class="bbc_img" />


Looking at the last bit : MISO line is shifting from 1 to 0 when clocks rises to 1. In CPOL=0 and CPHA=0 the readings are done exactly when clock is rising to 1. Sometimes I get a 0x88 and sometimes a 0x089. Like there is some kind of delay ?

The slave appears to be listening  (MISO message ok) because it sends back the same amount of bites and a response close to the one it should be. I guess the slave response gets somehow delayed. I guess the problem is somewhere in my board.

SPI lines are about 10 cm and length equal.

" alt="" class="bbc_img" />

And just for you info, I have the same behavior with another custom board, with another ATWINC1500 module and even using another SPI peripherial. I also tried to hand solder a module to my custom board with only the strict minimum lines (SPI_CFG, 3xSPI, CS, RST, EN, VDDIO, VBAT and GND). Same strange behavior.

 
Do you have any recommendations ? Where should I look (soft, hard)? I am really desperate, I do not know even where to look now.. All suggestion are welcome. If you need more schematics or info just ask.

 
Thanks for your help.

 
JPM

P.S.:First post here. I've been in the forum many times before (here is where I read many advices before buying my oscilloscope) and I enjoy Dave's Youtube channe!

[Dabbot]

Welcome to the forum!

The invalid response is the cyan trace I'm assuming, on the MISO line? Yes, as you said, you are getting 0x88 or 0x89 because, at the LSb, the slave is transitioning on the capturing edge of the clock (rising edge, with your settings). It should not be doing this.

How many devices are on that line? Also, what is your slave select line doing?

[JPMartinez]

Hi Thanks!!

The invalid response is the cyan trace I'm assuming, on the MISO line?

Yes. Sorry for not talking about the colors :

• Purple - CS
• Yellow - Clock
• Cyan - MISO
• Blue -MOSI

How many devices are on that line?

The line is exclusively for the ATWINC. SPI3 in my STM32L151vet6 to be exact. Tested it in SPI2 and had the same problem.

Also, what is your slave select line doing?

CS stays low during the whole transmission. See attached picture.

 

Thanks for your help!

[djglaze]

Hi JPM,

I've got some ideas that may or may not help you.  A bit over a year ago, I battled a different problem with the ATWINC1500 on my custom board that was exceedingly difficult to figure out.  There are some similarities between your story and mine, so there may be a common root cause.

I was communicating with my ATWINC1500 using SPI at 16MHz.  I was trying to get firmware updating of the WINC to work, but as I was doing the appropriate communication to set it up, the WINC would frequently just not respond correctly during a device reset/wakeup and all further communication would stop working.  Probing with an oscilloscope indicated that the signals were beautiful and well-within spec for rise times and such.  I picked up a nice logic analyzer and studied the messages being sent, and couldn't find a difference between working and non-working communication.

My board is run by an ATxmega chip, and I am not using the ASF library for my project (mostly because it's a hobby and I wanted the learning experience with writing all the drivers myself).  I am still using the host-side ATWINC1500 driver from the ASF, however, because it's way too much to reverse-engineer.  I tried doing the same operations using their demo software on one of Atmel's ARM processor demo boards with the ATWINC1500 demo board plugged into it, and it worked perfectly every time.  I was finally able to reproduce the failure on their demo board by stripping out ASF usage and hand-writing some basic operations (like pin toggling and such, used for the SPI protocol).  I worked with support at Microchip for a long time, now that I had a demonstrator program I could send them for hardware they had in their hands.  They tried, but couldn't figure it out.  I eventually figured out a hack workaround, and their suggestion was to keep using my hack as a permanent fix.

Since you're using a STM microcontroller, I'm assuming that you're not using the ASF (other than the WINC driver) like me.  That turned out to be the main problem for me: my drivers were too good.    The ASF drivers to toggle a pin's output goes through several layers of function calls with wacky logic at each step.  My driver just directly sets the right bit to toggle the port.  My driver was too fast.  I eventually figured out that adding a 200ns delay at a single place in their host-side WINC driver fixed the problem.  I was toggling a pin too soon in a sequence to be detected by their hardware.

Here's my fix: In their spi_cmd_rsp() function in nmspi.c, there's a loop that looks like this:

Code: [Select]

/* wait for response */
s8RetryCnt = SPI_RESP_RETRY_COUNT;
do
{
  if (M2M_SUCCESS != nmi_spi_read(&rsp, 1)) {
    M2M_ERR("[nmi spi]: Failed cmd response read, bus error...\n");
    result = N_FAIL;
    goto _fail_;
  }
} while((rsp != cmd) && (s8RetryCnt-- >0));

I added a 1ms delay at the bottom of the loop (which is important to get it inserted at the right place in the communication sequence):

Code: [Select]

/* wait for response */
s8RetryCnt = SPI_RESP_RETRY_COUNT;
do
{
  if (M2M_SUCCESS != nmi_spi_read(&rsp, 1)) {
    M2M_ERR("[nmi spi]: Failed cmd response read, bus error...\n");
    result = N_FAIL;
    goto _fail_;
  }
  nm_bsp_sleep(1);  // Hack to avoid timing problems
} while((rsp != cmd) && (s8RetryCnt-- >0));

It might be worth a try to see if this (or something similar) fixes it for you.  Slowing down all communication when I only needed the delay for this one precise call in a rare sequence of events bothered me, so I actually snaked down to here a separate chain of custom calls used during firmware updating to slow things down, and I used an unmodified version of this function for all other communication.  We're only talking about 1ms here, though, so leaving this in all the time probably isn't the worst thing.

Hope this helps!
Dave

[JPMartinez]

Hi Dave,

Thank-you for your message! I appreciate the time you took to write such a long explanation.

I tried to wake-up the chip using the ASF driver but even your your fix I had no success... I tried many things but after I while I understood that the problem was not the ATWINC chip but rather my STM32 config. I had a better look into the signal with my oscilloscope and found strange delays and different levels. For example sometimes CLK was floating at about 1.6 V. So I activated the STM32 internal pull-down resistor of the CLK line and finally success!!!!!!! Pull-down resistor works. Pull-up does not.

I haven't understood exactly why my circuit needs that pull-down resistor but at least now I can continue working and stop working full time trying to solve this thing.

But there is something I cannot yet explain. Without the fix I had different behavior in many boards :
Custom STM32L151vetx board    -> Wrong MISO message & CS goes low for 1ms
Blue pill (STM32F103cbt6)          -> Wrong MISO message & CS goes low for 1ms
Nucleo STM32L152                     -> Good MISO message & CS goes low for 25 ms

I had exactly the same parameters and code for the 3 boards: same speed, same GPIO config, same SPI config. The projects were generated with STM32CubeMx. That's crazy 
I guess my custom board (as well as the Bluepill) have some sort of problems with interference or poor routing.. I will be more careful next time and maybe add a filter with some passive components in the SPI lines.


Your message about timing/delay made me look further into the signal and eventually led me to the fix me so thanks

Ciao!

Jean

[Maximus225]

Hi there,

 I have ported WIFI drivers onto stm development board. I'm trying to create simple udp server or client connection. Until now i have tested the Access Point and Station Mode successfully. But i couldnt get pass this error.

 

(640)Tsf join Done
T(970)(M2M)Time Of Day
        5/03/2021 10:11:05 GMT
(970)(M2M)NTP time: 3829025465 from 132.163.96.3
(970)(M2M)(ERR)(m2m_hif_handle_req)(383)No of packets (3) in  Host Queue
 

IT should show some message stating that UDP Client test completed or something. But

After that the  module keep printing this message.

 

 

(120300)S HT 0 HR 3 R 23 T 0 AT 0 F 38 B 3, HPA:3, NPA:23 - stuck: 0

(120300)S HT 0 HR 3 R 23 T 0 AT 0 F 38 B 3, HPA:3, NPA:23 - stuck: 0

(120300)S HT 0 HR 3 R 23 T 0 AT 0 F 38 B 3, HPA:3, NPA:23 - stuck: 0

 

 

Does anyone have idea about the issue here.