SPI.transfer() hanging.

[noeldum]

I am adapting some code I used to use on an arduino UNO. My new target is an avr32db32.

I am using SPI1 and I get the SPI.transfer() function hanging and blocking the code. I am not used to this behaviour with the UNO.
I can see the tansfer() code has a while loop which could explain but I can't figure out the source of the problem.

This is used to communicate with a mcp3208 chip. Fairly straight forward.
I tested the hardware with a bitbanged SPI. It runs perfectly well. So there are no hardware problems to question here I think.
(let me know if I should post my bit banged code here also).

The only things to note is that I am using a different SS than defined by my swap. I would not think this could interfere, should it?

My bench testing code is here below.

Would you be able to point me in the right direction to troubleshoot this?

#include <SPI.h>

void setup() {
  Serial.begin(38400);
  Serial.println(F("# SPI TEST"));
  SPI.swap(SPI1_SWAP_DEFAULT);
  SPI.begin();
  pinMode(PIN_PF2, OUTPUT);
}

void loop() {
  uint16_t a;
  uint8_t channel = 2;
  uint8_t commandbits = 0b01100000 | ((channel & 0b111) << 2);

  //MCP3208_SS1_ON;
  PORTF.OUT &= ~_BV(2);

  (void) SPI.transfer(commandbits);
  uint8_t b1 = SPI.transfer(0);
  uint8_t b2 = SPI.transfer(0);

  //MCP3208_SS1_OFF;
  PORTF.OUT |= _BV(2);

  a = (b1 << 4) | (b2 >> 4);

  Serial.println(a);
}

[pcfreak1201]

Hi nodeldum!

...from the DX code:

/ These undocumented functions should not be used. except by advanced users
    // SPI.transfer() polls the hardware flag which is automatically cleared as the
    // AVR responds to SPI's interrupt.
    //
    // To use this, an ISR must be defined with the ISR() macro (you don't pass it any arguments. Attaching interrupts like that would
    // essentially guarantee that the exact thing you were trying to avoid (missing bytes) would occur, due to the grotesque
    // overhead inherrent in any ISR that calls a function that the compiler doesn't inline; a function called from a function pointer
    // can never be inlined - that imposes about 45 clocks of overhead on an ISR when you're using the interrupt to try to keep up with
    // the SPI bus. In the scheme of things, the maximum clock speeds an AVR's SPI can handle (as slave, clock / 4, or 6 MHz on Dx. But
    // at that speed you have just 32 clock cycles per byte. I don't see that happening except by polling. At half that, though, a well
    // written interrupt driven system should definitely be viable. At half of *that*, the same interrupt had it been attached() with an
    // attach method that took the function pointer.
    // Using these methods are not recommended, and is not for the feint of heart or dull of mind.

... and I don't see any ISR()?

[noeldum]

Thank you.
I did miss the ISR bit yes.
Is there an simple example for using SPI somewhere?