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 :
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......