Helpful ReplyGetting the MRF24WB0M to work

Senior Member
2012/04/15 03:52:10
I'm trying to connect a wifi module to a custom board on a breadboard. The MCU is a 695F512H, SPI1 is unavailable, SPI2 is dedicated to an SD, so I chose SPI3 to connect to the MRF. It appears such a connection has never even been thought of by MCHP. My hardwareprofile.h includes
 #define WF_CS_TRIS			(TRISDbits.TRISD9) #define WF_CS_IO			(LATDbits.LATD9) #define WF_SDI_TRIS			(TRISDbits.TRISD2) #define WF_SCK_TRIS			(TRISDbits.TRISD1) #define WF_SDO_TRIS			(TRISDbits.TRISD3) #define WF_RESET_TRIS                   (TRISBbits.TRISB1) #define WF_RESET_IO			(LATBbits.LATB1) #define WF_HIBERNATE_TRIS               (TRISDbits.TRISD0) #define	WF_HIBERNATE_IO                 (PORTDbits.RD0)  #define WF_INT_TRIS			(TRISDbits.TRISD8) #define WF_INT_IO			(PORTDbits.RD8) #define WF_INT_EDGE			(INTCONbits.INT1EP) #define WF_INT_IE			(IEC0bits.INT1IE) #define WF_INT_IE_CLEAR                 (IEC0CLR) #define WF_INT_IE_SET                   (IEC0SET) #define WF_INT_IF			(IFS0bits.INT1IF) #define WF_INT_IF_CLEAR                 (IFS0CLR) #define WF_INT_IF_SET                   (IFS0SET) #define WF_INT_BIT                      (0x80)  #define WF_INT_IPCCLR                   (IPC1CLR) #define WF_INT_IPC_MASK                 (0x1C000000) #define WF_INT_IPCSET                   (IPC1SET) #define WF_INT_IPC_VALUE                (0x0C)  #define WF_SPI_IF			(IFS0bits.SPI3EIF) #define WF_SSPBUF			(SPI3BUF) #define WF_SPISTAT			(SPI3STAT) #define WF_SPISTATbits                  (SPI3STATbits) #define WF_SPICON1			(SPI3CON) #define WF_SPICON1bits                  (SPI3CONbits) //#define WF_SPICON2			(SPI3CON2) #define WF_SPI_IE			(IEC0bits.SPI3EIE) #define WF_SPI_IE_CLEAR                 (IEC0CLR) #define WF_SPI_INT_BITS                 (0x1C000000) #define WF_SPI_IP			(IPC6bits.SPI3IP) #define WF_SPI_BRG                      (SPI3BRG) #define WF_MAX_SPI_FREQ                 (1000000ul)
The init sequence starts from WFInit.c at line 127 where there are instructions WFHardwareInit(); RawInit(); In this last one it gets stuck following this call sequence
WaitForRawMoveComplete(UINT8 rawId = 0x01) at C:/Microchip Solutions/Microchip/TCPIP Stack/WiFi/WFDriverRaw.c:654 RawMove(UINT8 rawId = 0x01) at C:/Microchip Solutions/Microchip/TCPIP Stack/WiFi/WFDriverRaw.c:428	 ScratchUnmount(UINT8 rawId = 0x01) at C:/Microchip Solutions/Microchip/TCPIP Stack/WiFi/WFDriverRaw.c:319] RawInit() at C:/Microchip Solutions/Microchip/TCPIP Stack/WiFi/WFMac.c:573	 
it gets stuck in this cycle
 while (1)     {         /* if received an external interrupt that signalled the RAW Move */         /* completed then break out of this loop                         */ 	    if(RawMoveState.rawInterrupt & rawIntMask) 	    { 		    break; 	    } 	             #if defined(WF_DEBUG) 	    /* If timed out waiting for RAW Move complete than lock up */         if (TickGet() - startTickCount >= maxAllowedTicks) 	    {     	    WF_ASSERT(FALSE); 	    }         #endif              } /* end while */
Now how can I debug this and see what's happening and what is wrong? There is no clear description of register values. Also could anyone share his basic Wifi project tree? I had to include lots of files and my project (almost no code of mine at all beside the rtos) is 250KB!!! I am sure there are lots of useless things.
Aussie Susan
Super Member
Re:Getting the MRF24WB0M to work 2012/04/15 19:45:04
I don't think is is necessarily that MicroChip have not thought of SPi3, but that there are some possible bugs in the software as this type of problem has been reported elsewhere (I get it occasionally with my circuit - there I put it down to my not properly designing the board and having possible temperature-dependent short between the bottom of the MRF24WB0MA and my PCB!).

The software seems to use the defined values consistently so as long as you have thee correctly defined then you should be OK.

As for the size of your program cost, the WiFi stack is quite large. There are a number of "#define"s that let you select what functionality is included which might help. Also defining buffer sizes and counts can impact on the data usage as well.

Super Member
Re:Getting the MRF24WB0M to work 2012/04/15 23:46:19
Make sure that the external interrupt from the MRF24WB0MA is working.

Also, do not use WF_RETRY_FOREVER as list retry count when trying to connect (which is the default for networktype WF_INFRASTRUCTURE). Set it to a lower value and handle reconnections yourself. WF_RETRY_FOREVER can get stuck in a deadlock, but I don't think it is the one you are experiencing here.

Senior Member
Re:Getting the MRF24WB0M to work 2012/04/16 00:52:41
No it doesn't even get there. It gets stuck in the early initialization, but it's difficult to debug this thing when you have no information on its actual internal configuration and what it should be. Moreover it seems PIC32 support has been added just as of late: defines, macros and delays are designed for PIC18! It makes use of 2 SPICON SFRs, while the 32 has just one; it looks for just 1 interrupt for the SPI while the 32 has 3... It appears to me this library hasn't been optimized for the 32...
MCU16 Applications
Re:Getting the MRF24WB0M to work 2012/04/16 02:17:09
I think you have a narcissistic view of your application. TCP/IP Stack libraries are large and complicated to begin with, but in Microchip's case it is also cross platform, which adds further complications. PIC18, PIC24/dsPIC, and PIC32 architectures all have differences, so to make the same stack codebase work simultaneously on all platforms, some portions have to be written a special way. In general, this means developing the code for the least capable hardware (i.e. PIC18) and emulating equivalent behavior when you have faster, more capable hardware that is different (i.e. PIC32). This is why certain macro definitions may appear convoluted, like the two SPICON SFR definitions. Stack support for the PIC32 has existed ever since PIC32 hardware has existed and this support predates the stack's support of Wi-Fi due to hardware existence. Neither PIC32 nor Wi-Fi are recent additions.

Rather than thinking the stack has upwards of 250KBytes of "useless things" in it, I'd recommend thinking of it as having a lot of features and protocol support that you may someday need and be glad has already been written for you. Anyway, the stack is very modular, so to get rid of unused features, simply use the TCPIP Configuration Wizard or comment out the applicable macros in your TCPIPConfig header directly. Also note that as a source library (as opposed to precompiled object library), the stack size will depend heavily on the C compiler optimizations. The default MPLAB projects will most likely use debug mode. Switching to the -Os (min size) optimization will shrink the code dramatically. It is possible to set C compiler optimizations on a per file basis rather than project wide, so once you get the stack working, you can individually turn on optimizations on the stack files so they are small while keeping your application code on the debug optimization level for development.

Since this appears to be the first time you are using the Microchip stack, I highly recommend you start with Microchip demo boards (ex: Explorer 16, PIC32 PIM, and MRF24WB0MA Wi-Fi PICtail Plus card). You'll save a lot of time (and probably money) by starting your learning process on a working platform. You'll find that things like MRF24WB0Mx register documentation isn't necessary for porting the code to your custom hardware. An oscilloscope and debugger should be all you need.

Also, I highly recommend starting with a pre-existing and working demo project (ex: Demo App\C32-EX16_MRF24WB.mcp), not trying to merge the stack into your application project. Merging your application and RTOS into the stack is a lot easier and more likely to work since the stack is bigger, more complicated, and more foreign to you than your own code is. 
Senior Member
Re:Getting the MRF24WB0M to work 2012/04/16 02:32:14
I have a MEB, and I used a pre-existing demo designed to run on it.
But it's useless if you want to design your platform:
not only does the MEB use either SPI1 or SPI2 (don't know which, but it's non-important), moreover it uses a CPLD.
So it doesn't simplify anything.
I'm working with a pre-existing carrier board, and using available pins.
SPI2 is taken and SPI1 doesn't exist, so I'm stuck with SPI3.
When referring to "useless things" I meant that I couldn't find a bare-minimum Microchip suggested project-tree, depicting the minimum source files necessary to get the stack working.
To be safe I included most of the TCPIP stack and this surely bloated the project and inflated its size.
Given there is not 18F with 256KB flash, I suppose this isn't the absolute minimum stack size.
So I'm not narcisistic about my project, I'm finding another black hole in the MCHP documentation:
-you have no way of knowing how the MRF24WB0M should be configured
-you have no way of knowing how the stack should be included.
Surely trial&error would give those information, but I better read them somewhere then loose my time with hit&miss.
Off Topic
Also, regarding multi-platform support: sometimes it gets stupid.
Supporting technologies spanning different ages with the same product may lead to suicide.
What's the point in using PIC18 definitions and architecture on a PIC32?
It's so much more powerful than a 18 that this looks like a waste.
Remember Microsoft with its win95 through winXP?
Bringing dos along didn't do that much a favor.
Same goes for the Flight Simulator brand: from FS98 which first introduced 3d mesh support, it got bloated and bloated through fs2000, fs2002 and finally fs2004. All to support every possible incarnation from fs5 to fs2004.
The product didn't run smoothly even on machines produced 2 years AFTER the software!
Sometimes you have to make hard decisions...
/Off Topic
post edited by erupter - 2012/04/16 02:33:26
New Member
☄ Helpful
Re:Getting the MRF24WB0M to work 2012/04/17 01:10:52
erupterWhen referring to "useless things" I meant that I couldn't find a bare-minimum Microchip suggested project-tree, depicting the minimum source files necessary to get the stack working.
Try open document Microchip TCP/IP stack Help and find "Required Files" which are : Using the stack->How the stack works ->Required File. I also have a lots of problem with MRF24WB0M how to configure this even I based on demo.
Senior Member
Re:Getting the MRF24WB0M to work 2012/04/17 02:12:42
Miro what's your hardware platform?

Thank you for the document advice, I'll have a look.
New Member
Re:Getting the MRF24WB0M to work 2012/04/19 02:14:03
At the beginning I used explorer 16 with Wi-Fi PICtail/PICtail Plus Daughter Board and of course appropriate demo. Now we use own hardware (software also) platform based on previous experience. But we have some trouble with MFR24WB under specific circumstamces (I hope you will not have it).
New Member
Re:Getting the MRF24WB0M to work 2012/09/18 05:35:12
I'd like to know where can I get a reference manual of MRF24WB0M...?ooking of microchip web site I've just found the Data Sheet...
Could you send me a link where to find a RM?
Many thanks.