2015/03/12 08:42:35
OK - so I am building up an app based on a Digilent Wi-Fire board. This board has a MRF24WG0MA module fitted on SPI4.
I have added the WiFi driver, and the TCPIP stack. Pointed the stack at the Wifi, pointed the wifi at SPI4, and the SPI in MHC shows as ; The instance is in use by the WiFi driver do not change settings.
So it all looks like its linked correctly BUT during Initialisation it just hangs.....
In drv_wifi_init.c - at the line with ResetPll() being called. Well inside there actually.
Looks to me like the SPI is not being clocked, so the routine is hanging waiting for a response from the hardware.
What I can't figure is why there seems to be no clock. It claims to be set up to run at 8 MHz (well within the 25 of the wifi module). All my other IO pins are correct - RESET is high, HIBERNATE is low, CE is low.
This is all in the generated code before we even start any application layer :-(. Oh I also have 6 x UARTS and FREERTOS installed, all of which were working before I introduced TCP and WIFI - all at the full 200 MHz.
Its probably something stupid - but the MHC masks much of what is happening 'under the hood' :-O. It also makes it FAR too easy to turn something off by mistake :-(.
Anyone got an idea where my SPI clocks are ???? - if thats really the issue ;-).

2015/03/13 09:44:59
Hi Graham
Just to summarize you have done:
  1. Turned on the Wi-Fi driver in the MHC
  2. Turned on the SPI driver in the MHC, and set the SPI driver instance to use SPI_ID_4
  3. Pointed the TCP/IP stack to use the Wi-Fi driver
I didn't see in your steps that you went to the Pin management screens and made sure to select the right pins for SPI_ID_4.  Can you verify that you did that?  It'll also tell you if you are having any pin conflicts between the UARTs and the SPI pins.
Also do you have a logic analyzer or oscilloscope you can put onto the clock pin to see if it is being clocked?
2015/03/14 07:31:51
Thanks for the response ;-)).
In short - yes the pins are all mapped and everything 'seems' to be set correctly. this despite MHC disconnecting the pins if I inadvertantly make a change :-((.
Current status is that as I cannot get to these pins (easily - as they only go from CPU to WIFI module on the PCB.). So - I decided to try a similar test using a different set of pins. I fired up a config using SPI6 (as SCK6 can appear on an IO connector on this particular board ;-). I slowed down the SPI speed to allow me to use an old PicKit2 as a 3 channel 'scope.
Initialization is all being done in the system files as expected, so I just 'Open' the SPI, then send 8 bytes out using  :
bufHandle = DRV_SPI_BufferAddWrite(spitesthandle, myBuffer, myBufferSize, NULL, NULL );
(ie straight out of the PDF ;-).
The data and clocks both appear on the pins as expected :-) - BUT the problem is in the buffer management of the driver - the following code ALWAYS returns DRV_SPI_BUFFER_EVENT_PENDING :
DRV_SPI_BUFFER_EVENT status = DRV_SPI_BufferStatus(spitesthandle);
So - I took a look to ensure that the SPI Tasks were being run and yes they are :
void _DRV_SPI_IDX3_Tasks(void)
vTaskDelay(1000 / portTICK_PERIOD_MS);
Yes its a tad slow - but at least I can 'see' what is happening at this speed ;-)).
I even stepped though as far as I could but it crashes when stepping in the SPI layers - it always has in my experience - way before Harmony. I have never successfully stepped through the lower layers of SPI interface.....
This code (above) is being called but is NOT changing the buffer status as expected, so my code 'hangs' - NB this is precisely how far the WIFI interface code gets, it gets stuck in a loop waiting for a DRV_SPI_BUFFER_EVENT_COMPLETE - which never happens.
So now I am down and dirty into the driver layer and trying to understand all the code I shouldn't even need to go near :-((.
Its probably some simple setting that I have wrong - but with no clear instructions as to what the Stack code (or even the SPI driver layer) EXPECTS the SPI to be set up as :-O - it makes life a tad difficult.
NB Having simulated the issue with the VERY simple SPI code above, this should allow me to find what is stopping it but I am having to go through a shed-load of unknown underlying driver code :-O.
Yes I have FREERTOS, but that is correctly scheduling my app task and the SPI driver task - so 'should' be just fine.
Should I set the SPI to be Interrupt or Polled - MHC seems to allow BOTH modes to co-exist :-O - very confusing......
Pity really - if these drivers (and MHC) were actually working - this would be one hell of a system ;-)). It has so much 'potential' but (as with everything) when you are at the 'bleeding edge' - you seem to waste a lot of blood ;-)).
I'll get there but its hard going in the down and dirty layers :-((. When I do finally fix it, I will post my findings....
Any thoughts from microchip would be most welcomed......
2015/03/14 09:47:52
Hi again,
For anyone who finds themselves in the same situation......
I printed the whole SPI driver section and re-read it - carefully !!.
My second problem - the SPI6 test code is actually wrong (thanks Microchip ;-)). I wrote my test code based on their example (PDF 1.03.01 page 862) - it has an error !!! - as does the function definition on page 875.
1. Example on page 862 says get a handle from Open, use this to send the data, then ALSO use this to request the buffer status - WRONG!! - the code (near the end of the page) uses 'handle' to get buffer status it SHOULD us bufferHandle. With that fix - it now works as expected.
2. The function definition on page 875 also tells us to use 'handle' as returned from DRV_SPI_Open (see the comment!!). Same problem its the wrong handle !!!
So this now leaves me with my original issue - that of the WiFi driver - BUT in re-reading this section I can see why the generated code is failing !!. The code to initialize the stack (called in Sys_Initialize) goes down to a routine which interfaces with the SPI. This code 'claims' (by function name) to use a bit-banged interface to the SPI, but in fact calls IspSpi_Tx - which in turn calls DRV_SPI_BufferAddWrite and then proceeds to wait for a DRV_SPI_BUFFER_EVENT_COMPLETE.
Sounds fine - until you read the bit where the actual buffer handling is done in the SPI's Tasks function (and not inline in the above BufferAddWrite function) - which of course is NOT YET RUNNING because we are still Initializing the interface and have not yet reached the point where any SYS_Tasks functions are being called :-O.
So its a classic Catch 22 situation. This FUDGE code (Reset_PLL) - apparently 'waiting for Rev A2 silicon' ???? cannot work.
Please accept my apologies of course if I am wrong here :-)).
So is this RevA2 silicon referring to the CPU or to the WIFI module - I assume WiFi.
So all I now need is to figure out a workaround :-O. Maybe I'll just comment out this line of code :-O in two places :-O - and see what happens :-O - as I don't (yet) have a clue as to how to find the Silicon rev in my wifi module :-((.
Any advice or fix from Microchip will be well received.
Many Thanks
2015/03/14 11:31:48
In looking at one of the Harmony WiFi samples that worked for me, I see 
  while(!(DRV_SPI_BUFFER_EVENT_COMPLETE & DRV_SPI_BufferStatus (spiBufferHandleTx) )) //Check for the successful data transfer
        DRV_SPI_Tasks (drvSPIObject);

 It appears that they manually call DRV_SPI_Tasks() because they know the tasks aren't running yet.   So there must be something else going on to block it.
2015/03/14 11:47:42
Yup - just spotted that myself - hence just coming back in to apologise/comment to that effect ;-)).
I'll go through the settings - again - :-O. Probably not set the right CE pin or something else stupid.
Thanks for the response though
2015/03/14 12:41:12
Should I set the SPI to be Interrupt or Polled

  I looked at the sample in apps \ tcpip \web_server_nvm_mpfs which has a WiFi configuration.   I think that's the one I based my code on.    It appears to be using SPI in polled mode, which surprises me.
Also, if you can get to the part that is blocking in the debugger, inspect the SPI*CON configuration registers to confirm that the SPI has been initialized and enabled.
2015/03/15 11:04:44
Sorry - I must have missed this app - when I looked I didn't find one listed with the wifi module - obviously didn't look well enough!!.
So - it didn't really help me, but the following might just help someone else with this issue - and maybe even elicit a FIX ;-)) :
OK - so I have managed to get past this problem and am now (hopefully) back on-track commissioning the wifi code.
For anyone who wants/needs to know......
In file drv_wifi_spi_c Line 141 gets called (on my MZ system anyway) :
Oh look - the SPI_INDEX is hard-coded :-O - to index 0. Thats why my SPI module (although it was Initialised) was never getting actually switched ON.
On my board I have 4 active SPI interfaces defined and my WIFI was specified as Index 2 - perfectly legit according to MHC !! - So much for this being 'Production release' code :-((.
Hope Microchip is reading this - please fix this guys - it just wasted a good 2+ days for me to track this down :-((.
So - not yet out of the woods - but at least back where I should have been on Friday morning :-)).
Good Luck if this helps someone ;-)) and thanks to bikeoid for helpful suggestions ;-).
2015/03/15 17:22:23

 Wow - I vaguely remember running across something like this when I was trying to understand the sample project with the predefined PIC32MZ starter kit configuration.   However, I wasn't sure if I was looking at a "project file" or a "library file".   Apparently someone at Microchip was confused also, and modified a library file incorrectly.
There's also the confusion of convention between logical *INDEX_0 and physical *INDEX_0 when configuring subsystems.     I still don't have it all quite straight.
I'll be getting my first article design to check out in about 4 weeks - I would have run into the same problem (I defined my application SPI interfaces before the WiFi module).
2015/03/16 01:09:52
Glad it helped someone ;-)) Best of luck....
© 2020 APG vNext Commercial Version 4.5

Use My Existing Forum Account