WINC1500 never asserting IRQn

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

I'm porting the WINC1500 driver to our architecture, but I'm facing some problems I can't figure out.).

We are using a  a ATWINC1500-MR210PB module, and we started from the Atmel driver (we ported the nm_bsp_xxx.c and nm_bus_wrapper_xxx.c source files).

The SPI is working as expected (i.e., I can read the firmware revision register without problems), but the IRQn signal is always high, so the irq handler function is never called.

It doesn't look like hardware problem (the IRQ line has a weak pullup), but I can't find any documentation on how to port the driver and how communication actually should work (should the WINC1500 assert the IRQn signal? when?).

 

Any suggestion? Is there a complete porting guide?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

 

do anybody can help me to port the same drivers (same chip, same channel) and make the chip works?

Any help would be apreciated

 

g

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi together,

 

i right now ported the WINC1500 MR210PA for an infineon controller.

First of all the SPI configuration must be:

  • Baud rate = 100000 (it is the same as for the samd21)
  • Shift direct = MSB first
  • No start bit
  • No stop bit
  • SPI_SCK PIN config: Push Pull output
  • SPI_MISO config: Pull down input
  • SPI_MOSI config: Push Pull output
  • SPI_SSN  config: Push Pull output

 

This configuration must be inserted in the "nm_bus_init" function in the "nm_bus_wrapper_samd21.c" module. Also the function "spi_rw, nm_bus_deinit, bus_reinit" must be adjusted.

 

The configuration for the external Interrupt "IRQN" is as following:

  • Input Pin
  • Pull-Up
  • Must trigger an interrupt by detecting a falling edge of the IRQN signal
  • The interrupt function is the "chip_isr" function 

 

All this must be done on the "nm_bsp_samd21.c" module in the function "nm_bsp_register_isr". Also the function "nm_bsp_interrupt_ctrl" must also be adjusted.

 

Also don't forget to configure the PINs RESET_N, CHIP_EN, WAKE in the module "nm_bsp_samd21.c" in the function "init_chip_pins" to be able to make a reset of the WINC1500 module. To be able to reset the WINC1500 module you also have to adjust the function "nm_bsp_reset" for your target system.

 

Adjust the UART configuration to be able to use the "printf".

 

The "conf_winc.h" file must also be adjusted, because here are some values which the software stack from the WINC1500 is needed. So don't forget to copy this file, too. Here you need to adjust the defines for your target system like "CONF_WINC_SPI_CLOCK" or "CONF_WINC_PRINTF".

 

The software stack which is needed for the WINC1500 on an other host controller consists of all the files which lies under the "wifi" (/src/ASF/components/wifi/) folder from the Atmel example projects.

I also copied the files from the folder "/src/ASF/sam0/utils/stdio".

 

For the Compiler you also need to define the following defines:

  • CONF_WINC_USE_SPI
  • BAUDRATE
  • MODULE_UART_INT
  • NM_EDGE_INTERRUPT (this define is importend for the IRQN control PIN)

 

I hope this help you to port the WINC1500 to an other host controller.

 

Best Regards.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure if this thread will get checked but ...

 

Is it possible to port the WINC1500 and not use the IRQN pin? I'm thinking of just simply polling the device and checking it in the main loop by constantly calling m2m_wifi_handle_events().

 

However, I also have another problem at the moment - I am having SPI communication issues. I am using an ATmega128 and have altered the base source files for the bus wrapper.

My scope says I am sending and receiving data ok on the bus, but I get constant read issues from the TWINC1500.

 

From nm_spi.c:

 

(APP)(ERR)[nm_spi_init][718][nmi spi]: Failed internal read protocol with CRC on, retyring with CRC off...

(APP)(ERR)[spi_data_read][365][nmi spi]: Failed data response read...(00)

(APP)(ERR)[spi_read_reg][604][nmi spi]: Failed data read...

(APP)(ERR)[nm_spi_init][721][nmi spi]: Failed internal read protocol...

 

 

I step through the board reset process and it's pulling the lines up and down correctly. I have also slowed the SPI clock right down and tried a variety of speeds.

The wave forms from the scope look like they are at the correct levels too.

 

Anyone have any suggestions? I can post a log of values sent and received over SPI if needed.

 

Edit:

(According to the software guide.)

To clarify, I send these bytes over the SPI bus in this order from the master --> 0xCA, 0x00, 0x10, 0x00, 0xCA

 

The response I expect is : 0xCA, 0x00, 0x00, 0xF3, 0xA0, 0x03 etc etc

 

Instead I get: 0x08, 0x07, 0x30, 0x00, 0x80, 0x00, 0x20

 

then a bunch of 0x00's while the master tries to send a soft reset command.

As far as I can tell, the slave's response is invalid as it should start with a 0xCA in response to the masters command, even if it's sending an error. I've tried looking to see what that sequence of values means but it appears to be just garbage, albeit consistent garbage (as in repeatable).

 

 

 

 

Last Edited: Mon. Sep 19, 2016 - 05:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

I'm having the same issue with the not working IRQ.

I can communicate with the module over SPI without any problems.

I can e.g. read the firmware version (19.4.4) or the MAC Address.

 

But the IRQ line is never being pulled low by the device.

I tried station mode and AP mode. Command returns with OK, but no IRQ...

 

I don't know where to start searching for a solution.

Any ideas?

 

Michael

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll answer my own question:

 

Even I can read out firmware version or MAC address , there's no IRQ or error return if

the SPI master clocks out HIGH levels for reading !!!!

I couldn't find any hint in the manual that the master need to clock out LOW levels on reading.

This is a strange behaviour.

 

But now I get an interrupt.

 

Michael

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I ported the driver to an MSP430 microcontroller, and one of the problems I encountered was that sometimes a NULL pointer was given as the SPI transmit or receive buffer. If a null pointer is given as the transmit buffer, simply send 0x00's, otherwise you may get 'unpredictable outcomes'. Don't know if this helps you...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey Taste Test,

do you have solved your problem with the wifi module from atmel?

because i have the same problems with the module. i have send with the ATSAMD21 over SPI the Info Bytes 0xCA... and i became the same answer. How do you solve it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The IRQ pin configuration is done in conf_winc.h and in nm_bsp_samd21.h. The interrupt should be configured as falling edge. the power up sequence of the ATWINC1500 should be as per the section 9.3 Power-Up/Down Sequence and this is controlled by the CHIP_EN,RESETN and WAKE lines. These GPIOs are also configured in conf_winc.h

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Michael. Can you please explain how exactly you solved your problem with the IRQ on winc1500. I am having the same problem, I get the firmware version and other communication seems to work well but I do not have interrupt from winc1500. Confirmed with an oscilloscope.

What do you mean by "the master need to clock out LOW levels on reading. " Please share this knowledge as I am stuck here. I know this was a long time ago but I appreciate it very much if you can give me some clues for where I am getting it wrong. 

Also if anyone else have overcome this problem Please send some hints??

 

Regards 

​​​​​​​Dejan