Sammy C21 support for 2 TMC2209 drivers with UART com

Gixxerfast

@dc42 OK, let's see if this went OK.

Before with the induced fault:

Last reset 00:00:13 ago, cause: software
Last software reset at 2022-01-30 12:28, reason: deliberate HardFault, available RAM 232, slot 0
Software reset code 0x8060 ICSR 0x00000003 SP 0x20002b20 Task MAIN Freestk 758 ok
Stack: 20000001 00000000 00020104 00000001 00000000 00011491 00011fa8 01000000 00000000 4e49414d 20000f48 00000000 20001048 200036e4 ff003018 20003010 00000000 00017d25 00000000 00000000 a5a5a5a5 20002c08 200014ec 00000005 a5a5a5a5 20002c08 00000001

Then after with the "real" fault:

Last reset 00:00:44 ago, cause: software
Last software reset time unknown, reason: HardFault, available RAM 232, slot 1
Software reset code 0x0060 ICSR 0x00000003 SP 0x20007f00 Task MAIN Freestk 6126 ok
Stack: 20001048 200036e4 ff003018 20003010 00000000 00017d25 00018a58 0100000f 00000000 20002f94 20001d70 20001544 a5a5a5a5 a5a5a5a5 a5a5a5a5 00000000 00000005 00000000 20001d44 00018337 00000000 000174a1 20001544 fffffffd 20002f88 00000000 00000002

And the map file:
Duet3Firmware_SAMMYC21.map.stp

Please note that I had to change the file name extension to cheat the forum software.

I hope I executed this correctly.

dc42

@gixxerfast thanks. I think the main task stack may be overflowing, because the reported main task stack of 6126 is greater than the allocated amount. Try increasing it in line 54 of file Tasks.cpp. I suggest you increase it from 850 to 900. However, as you have so little RAM left you will have to reduce the TMC task stack size back to 100.

Gixxerfast

@dc42 Hi and thanks for the answer.

It did not remove the problem though. However I found this and I changed a bit and now it doesn't crash but then again I don't have any drivers after this it seems.

bool DoTransaction(size_t driverNumber)
{
	TmcDriverState *currentDriver;
#if TMC22xx_SINGLE_DRIVER
	currentDriver = driverStates;
//#elif TMC22xx_USE_SLAVEADDR //UER
//	const size_t mappedDriverNumber = ((driverNumber & 1u) << 2) | (driverNumber >> 1);	// this assumes we have between 5 and 8 drivers
//	currentDriver = &driverStates[mappedDriverNumber];
#else
	currentDriver = &driverStates[driverNumber];
#endif

It's the comment "// this assumes we have between 5 and 8 drivers" that makes me wonder.

Now, I don't know if the Samc is bigendian/littleendian but when I try that on the X86/Linux with G++ it looks a bit strange to me.

2022-01-30 14:53:23	M122 B124
Diagnostics for board 124:
Duet SAMMYC21 firmware version 3.4.0beta7+8 (2022-01-30 14:06:17)
Bootloader ID: not available
Never used RAM 224, free system stack 3888 words
Tasks: Move(notifyWait,0.0%,153) HEAT(notifyWait,0.0%,117) CanAsync(notifyWait,0.0%,64) CanRecv(notifyWait,0.0%,77) CanClock(notifyWait,0.0%,64) TMC(notifyWait,0.5%,61) MAIN(running,99.2%,470) IDLE(ready,0.0%,41) AIN(delaying,0.3%,154), total 100.0%
Last reset 00:45:33 ago, cause: software
Last software reset time unknown, reason: HardFault, available RAM 224, slot 2
Software reset code 0x0060 ICSR 0x00000003 SP 0x20007f00 Task MAIN Freestk 6126 ok
Stack: 20001048 200037b4 ff0030e8 200030e0 00000000 00017cf5 00018a28 0100000f 00000000 20003064 20001d70 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 00000000 20001d40 00000000 a5a5a5a5 00018307 00000000 00017471 00000000 fffffffd 20003058 00000000 00000002
Driver 0: pos 0, 160.0 steps/mm,not present, steps req 0 done 0
Driver 1: pos 0, 160.0 steps/mm,not present, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter -1/14, peak Rx sync delay 199, resyncs 0/0, no step interrupt scheduled
MCU temperature: min 26.9C, current 28.9C, max 29.0C
Last sensors broadcast 0x00000000 found 0 155 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 21718, send timeouts 0, received 35251, lost 0, free buffers 37, min 37, error reg 0
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0

dc42

@gixxerfast line 1606/1607 should be changed to:

#elif TMC22xx_USE_SLAVEADDR && TMC22xx_HAS_MUX
	const size_t mappedDriverNumber = ((driverNumber & 1u) << 2) | (driverNumber >> 1);	// this assumes we have between 5 and 8 drivers and a 2-way multiplexer

The fact that is now reporting the drivers are "not present" indicates that it is trying to talk to them. How did you connect the drivers to the sercom transmit and receive pins on the sammy?

dc42

PS - lines 1482-1484 are currently:

#if TMC22xx_HAS_MUX
	SetUartMux();
#endif

I think you may need instead:

#if TMC22xx_HAS_MUX
	SetUartMux();
#elif TMC22xx_USE_SLAVEADDR
	delay(2);							// give the previous TMC22xx driver time to get off the bus
#endif

Gixxerfast

@dc42

constexpr uint8_t TMC22xxSercomNumber = 3;
Sercom * const SERCOM_TMC22xx = SERCOM3;

constexpr Pin TMC22xxSercomTxPin = PortAPin(22);
constexpr GpioPinFunction TMC22xxSercomTxPinPeriphMode = GpioPinFunction::C;
constexpr Pin TMC22xxSercomRxPin = PortAPin(20);
constexpr GpioPinFunction TMC22xxSercomRxPinPeriphMode = GpioPinFunction::D;
constexpr uint8_t TMC22xxSercomRxPad = 2;
constexpr IRQn TMC22xxSercomIRQn = SERCOM3_IRQn;

I really hope I haven't messed up here.

Also, earlier I had to change this one too:

 inline void TmcDriverState::UartTmcHandler() noexcept
 {
-#if !(TMC22xx_HAS_MUX || TMC22xx_SINGLE_DRIVER)
+#if !(TMC22xx_HAS_MUX || TMC22xx_SINGLE_DRIVER || TMC22xx_USE_SLAVEADDR)
 # if TMC22xx_USES_SERCOM
        DmacManager::DisableCompletedInterrupt(TmcRxDmaChannel);
 # else

dc42

@gixxerfast yes that change to UartTmcHandler is correct.

The stepsticks need to be wired such that DRIVES_UART is routed to pin 14 of the TMC2209 chip as it is on the tool board. The MS1 and MS2 pins of the chip need to be both grounded for driver 0, whereas for driver 1, MS1 should be connected to +3.3V and MS2 grounded as you have illustrated.

Did you see my message about the SetUartMux call?

Gixxerfast

@dc42 said in Sammy C21 support for 2 TMC2209 drivers with UART com:

Did you see my message about the SetUartMux call?

Yes, if you mean this I have added that:

#if TMC22xx_HAS_MUX
	SetUartMux();
#elif TMC22xx_USE_SLAVEADDR
	delay(2);							// give the previous TMC22xx driver time to get off the bus
#endif

OK, I'll check the pin on the TMC2209 chip, but I think it should be alright.
EDIT: Yes, DRIVES_UART (via PDN_UART) is connected to pin 14 on the TMC2209 chip.

On the first step stick both MS1 and MS2 are connected to ground.

dc42

@gixxerfast lines 569 and 626 should also have || TMC22xx_USE_SLAVEADDR appended.

Gixxerfast

@dc42 OK thanks, done. Behaviour unchanged though.

dc42

@gixxerfast have you disabled I2C support in your SAMMYC21.h file? That also uses SERCOM3.

Gixxerfast

@dc42 Yes, I have. There are pin conlicts as well IIRC.

dc42

@gixxerfast please share your SAMMYC21.h file. Have you changed any other files except TMC22xx.cpp ?

If you set the number of drivers to 1, set TMC22xx_SINGLE_DRIVER to 1 and TMC22xx_USE_SLAVEADDR to 0, are you able to control driver 0?

Gixxerfast

@dc42 Sorry for the delay, I was just testing running it as a single driver but unfortunately it didn't work any better.
So either I have a fundamental hardware fault (even though i measured that all the lines goes to where they are supposed to according to the schematics) or the configuration is somehow still wrong.

My initial tests with step/dir worked so that part should be OK, but not the sercom/uart part.

I'll attach the SAMMYC21.h file (renamed to fool the forum software)

SAMMYC21.h.stp

Thanks for your help.

Forgot about the changed files. These are the files I have changed:

$ git status
On branch 3.4-dev
Your branch is up to date with 'origin/3.4-dev'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   src/Config/SAMMYC21.h
        modified:   src/Movement/StepperDrivers/TMC22xx.cpp
        modified:   src/Platform.cpp
        modified:   src/Tasks.cpp

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/Platform.cpp.save

dc42

@gixxerfast two suggestions:

It's not going to work without the voltage monitoring if you power up 5V before VIN, because the drivers won't respond to the UART data until VIN is present. You may be able to get round this by sending M999 B124 to restart the board after powering it up.
I suggest you concentrate on getting it working with a single driver and the UART to start with, because that configuration is known to work on the tool board.

What changes did you need to make to Platform.cpp ?

dc42

PS - in your SAMMYC21.h file you should not need the line "constexpr IRQn TMC22xxSercomIRQn = SERCOM3_IRQn;". Also you should enable stall detection in that file, to match the configuration used by working TMC2209 configurations.

Gixxerfast

@dc42 The board has a LMP78 regulator so VIN should be there at the same time of possibly before 5V if not the 100uF capacitors delays things.

Here's the changes I made in Platform.cpp to make it compile.

I agree, should continue with one driver and see

Gixxerfast

@dc42 Hi again. One thing before I put this aside for a while.

I see now that you (1LC and mini5+) pull PDN_UART high whilst the step sticks pulls it low.

That suggest to me that I might have to invert the signal to make it work. I might be barking up the wrong tree here but is that possible to do?

1LC:

BTT TMC 2209 Stepstick

Gixxerfast

@dc42 Yes!!! Win

Well, sort of anyway. I removed the pulldown resistor on the step stick and added this ugly 20k pullup resistor and now it works anyway.

2022-01-30 22:46:11	M122 B124
Diagnostics for board 124:
Duet SAMMYC21 firmware version 3.4.0beta7+8 (2022-01-30 19:28:27)
Bootloader ID: not available
Never used RAM 4808, free system stack 2745 words
Tasks: Move(notifyWait,0.0%,127) HEAT(notifyWait,0.0%,117) CanAsync(notifyWait,0.0%,65) CanRecv(notifyWait,0.0%,74) CanClock(notifyWait,0.0%,65) TMC(delaying,1.9%,49) MAIN(running,97.8%,471) IDLE(ready,0.0%,40) AIN(delaying,0.3%,154), total 100.0%
Last reset 00:05:31 ago, cause: power up
Last software reset time unknown, reason: HardFault, available RAM 224, slot 2
Software reset code 0x0060 ICSR 0x00000003 SP 0x20007f00 Task MAIN Freestk 6126 ok
Stack: 20001048 200037b4 ff0030e8 200030e0 00000000 00017cf5 00018a28 0100000f 00000000 20003064 20001d70 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 00000000 20001d40 00000000 a5a5a5a5 00018307 00000000 00017471 00000000 fffffffd 20003058 00000000 00000002
Driver 0: pos 16000, 160.0 steps/mm,stalled, standstill, SG min 0, read errors 0, write errors 0, ifcnt 14, reads 6229, writes 2, timeouts 0, DMA errors 0, CC errors 0, steps req 16000 done 16000
Moves scheduled 1, completed 1, in progress 0, hiccups 0, step errors 0, maxPrep 401, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter -1/12, peak Rx sync delay 200, resyncs 0/0, no step interrupt scheduled
MCU temperature: min 24.5C, current 26.8C, max 26.8C
Last sensors broadcast 0x00000000 found 0 114 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 2327, send timeouts 0, received 3743, lost 0, free buffers 37, min 37, error reg 0
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 300, adv 37058/37058

2022-01-30 22:50:56	m569.2 P124.0 R1
Register 0x01 value 0x00000001

Now, I don't know what to do about this later, can't remove resistors from step sticks and running jumpers.

dc42

@gixxerfast try using a pullup resistor of 4.7K or 3.3K. That might be enough to defeat the two 20K pulldown resistors without causing a problem for the Tx signal passing through the 1K series resistor.