[Solved] Understanding MISO Line with ATWINC1500 - Page 1
Forum section: electronics / general

author: JPMartinez
author_rank: Newbie
timestamp: January 15, 2021, 12:16:57 pm
content: 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. 21https://ww1.microchip.com/downloads/en/DeviceDoc/70005304D.pdfCode 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.pdfTo wake up the chip the MCU sends : 0xC4 0x80 0x01 0x00I 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 0x00I 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 :

author: Dabbot
author_rank: Regular Contributor
timestamp: January 15, 2021, 01:19:45 pm
content: 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?

author: JPMartinez
author_rank: Newbie
timestamp: January 15, 2021, 02:44:54 pm
content: Hi Thanks!!QuoteYes. Sorry for not talking about the colors :Purple - CSYellow - ClockCyan - MISOBlue -MOSIQuoteThe line is exclusively for the ATWINC. SPI3 in my STM32L151vet6 to be exact. Tested it in SPI2 and had the same problem.QuoteCS stays low during the whole transmission. See attached picture.Thanks for your help!

author: djglaze
author_rank: Newbie
timestamp: January 15, 2021, 05:47:33 pm
content: 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 theirspi_cmd_rsp()function innmspi.c, there's a loop that looks like this:Code:/* 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 thebottomof the loop (which is important to get it inserted at the right place in the communication sequence):Code:/* 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

author: JPMartinez
author_rank: Newbie
timestamp: January 20, 2021, 09:12:40 am
content: 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 1msBlue pill (STM32F103cbt6) -> Wrong MISO message & CS goes low for 1msNucleo STM32L152 -> Good MISO message & CS goes low for 25 msI 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 crazyI 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 thanksCiao!Jean

author: Maximus225
author_rank: Newbie
timestamp: May 06, 2021, 05:41:07 am
content: 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 DoneT(970)(M2M)Time Of Day5/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 QueueIT should show some message stating that UDP Client test completed or something. ButAfter 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: 0Does anyone have idea about the issue here.