Due getting stuck on SPI Transfer command

I have a code that runs fine on Mega board and recently got Due and started porting it over. Removed all the direct port access commands that are not relevant to Due and the code works fine except when I try to use SPI protocol, it hangs on SPI.transfer command

Here is a sample barebone code snippet that is being used for SPI communication

#include <SPI.h>
#define MAX5424_1CS       52
SPISettings settings(3000000, MSBFIRST, SPI_MODE0); 

void setup() {
  // put your setup code here, to run once: 
  // Initiate serial communication
  Serial.begin(9600);
//Setup MAX5424 CS pins
  pinMode(MAX5424_1CS, OUTPUT);
  digitalWrite(MAX5424_1CS, HIGH);
  updateDigiPot();
}

void updateDigiPot() {
  byte Out[3];
SPI.beginTransaction(settings);   
  //Pull CS low
  digitalWrite(MAX5424_1CS, LOW);  
  Serial.println("Begin SPI transfer ..");
Out[0] = 0x00; 
    SPI.transfer(Out[0]);
Out[1] = 0x4F; 
    SPI.transfer(Out[1]);
  //Pull CS High
  digitalWrite(MAX5424_1CS, HIGH);
  delay(10);
  SPI.endTransaction();
  Serial.println("SPI endTransaction ..");
}

void loop() {
  // put your main code here, to run repeatedly:

}

Serial monitor stops after showing Begin SPI transfer ..

But SPI.transfer works fine using just SPI.begin() command, why is that I am not able to use SPI.beginTransaction with settings command as suggested in the Due SPI page?

Any suggestions where I am missing something here?

Is it copy-paste problem or you really forgot about
void loop(){
...
}
?

No loop here, I can add that, but I think loop executes only after setup is done and this is getting stuck during setup itself.

Does not compile.

It should now....

I agree that expectation is to see second message from

Serial.println("SPI endTransaction ..");

Maybe it stops because of some fatal error in the middle of ```
updateDigiPot()

Try to use (for example) PB21 or D52 pin name
instead of #define MAX5424_1CS 52
Also I dont see that pin 52 is set as Output.

As I mentioned, if I update that function to as below

void updateDigiPot() {
  byte Out[3];
SPI.begin();   
  //Pull CS low
  digitalWrite(MAX5424_1CS, LOW);  
  Serial.println("Begin SPI transfer ..");
Out[0] = 0x00; 
    SPI.transfer(Out[0]);
Out[1] = 0x4F; 
    SPI.transfer(Out[1]);
  //Pull CS High
  digitalWrite(MAX5424_1CS, HIGH);
  delay(10);
  SPI.end();
  Serial.println("SPI endTransaction ..");
}

it works just fine

Did you try it on any non-DUE platforms ?

I use the same code on Mega without any issues and came across this when porting that code over to Due

Sorry - did not pay attention to that.
The only idea for now is SPI settings.
In beginTransaction you use your own settings.
In SPI.begin MCU uses some default settings.
or maybe a bug in SPI library

Oh, forgot to say:
When you use Transactions you still need to write SPI.begin somewhere

No need to be sorry, I should have been more thorough in my original post itself.

This is something I don't understand, on Mega, I don't use SPI.begin() anywhere and works just fine

I should have spotted that, no SPI.begin();, no wonder it does not work properly.

Just becuse of some quirk on the Mega you can ommit the required SPI.begin(); it does not mean its going to be OK on other platforms ........................

My only experience with Arduino is with many Mega boards, not familiar with other platforms, so I take it as a miracle quirk of it :grinning:. Will give this a try again using SPI.begin() and report back

Adding the required SPI.begin(); to the sketch you provided cures the problem on the DUE.

I do not have DUE board under hand - so, cannot try.
But here is what I guess:
beginTransaction at Mega, UNO and other traditional boards probably initiate SPI object automatically.
But DUE has very different processor.
It is possible that SPI object is not initiated properly by beginTransaction . And first call of SPI.transfer crashes everything.
Again - this is just a guess.

I just tried using SPI.begin() before calling beginTransaction and it worked. Looks like its something with Due only.

Take a look on this info (DUE SPI is very different)

Yes, I read that and it looks very handy feature, but I need more than those dedicated 3 CS pins, so, I ended up using my existing code.

MiniCore (ATmega328) has the same problem, miss out the required SPI.begin() and you have problems.