Custom 1HCL HW/FW bootloader issues

wayneosdias

I made a custom circuit based on the ATSAME51G19A/1HCL. I have the mcu in circuit and have programmed it with SAME_5x v2.11 with nEDBG programmer in Microchip Studio. The chip was erased, fuses set and memory flashed as outlined in the Duet update bootloader faq. Erasing and flashing the chip went fine as verified in Studio.

Ive attached the custom board to a 6HC via CAN cycled the power several times and Im still not getting any fw update requests in DWC or seeing any other boards attached in the OM. I put a logic analyzer on the custom board CAN rx line and are getting msgs, but the tx is sitting idle/high. The circuit follows the Duet 1HCL circuit in regard to OSC, CAN, Board type and SWD so I didn't think there is anything to change in the Bootloader FW config.

I did look at the SAME_5x v2.11 config file and noticed there's a 3-bit binary board type scheme, but no analog board type scheme as the 1HCL appears to use. Anyway, I don't know if that is imperative but can't see any other reason why I can get mcu running with bootloader.

Schematic of circuit attached, any help is much appreciated
Schematic_PNP_Head_2024-12-05 (1).pdf

wayneosdias

So I got antsy and have some 1HCLs laying around. I pulled the mcu from the OE 1HCL and swapped it into my custom board. The CAN now works and DWC and OM is working. I noticed the Bootloader FW is different than what I was attempting to use.

I looked up the 2.4 Bootloader and the readme states there is 1HCL specific changes in this the 2.4 ver. I never thought to look past 2.11 as it's the 'latest'. Any rate I'll work on getting my custom main fw on and see how it all goes...

Thanks guys

wayneosdias

After transfering the Duet 1HCL chip onto my custom pcb I was able to boot load my custom main FW and it mostly works as expected as an CAN expansion node.

I still don't know what is going on with the bootlaoder FW not working on the blank chip. After comparing the Boot FW 2.4 to 2.11 I wasn't coming to any conclusions and I impulsively swapped the OE Deut chip out for my blank chip to see if the 2.4 Boot FW would make a difference. Still no worky I know the custom HW is fine and the Bootloader FW ver doesnt seem to make a difference so it must be the fuses. Before I swapped the mcus the last go I took screen shots at the fuse settings. They appear different, but I dont know what or how to interpret them or if it is imperative that they match exactly.

Heres a comparison of the blank chip fuse setting on the L and the Duet 1HCL chip on the R. the different values are underscored red. Should I just set them to match? If anyone has any advice on setting the fuses would be greatly appreciated

Thank You

dc42

@wayneosdias a few points:

From the schematic I see you are using the MAX3051 CAN transceiver. I can see a couple of potential issues with this: (1) it uses a 3.3V supply so it is likely to produce lower voltage CAN signals that the devices we use, which use a 5V supply; (2) it is not CAN-FD + BRS compatible and has a maximum bit rate of 1Mbps. This means that it won't work with future versions of RRF when we enable BRS. All Duet 3 boards are designed to work with BRS up to 4Mbps in the data phase.
Your drivers don't have the UART pins connected, therefore you will be unable to set the TMC2209 motor current, standstill current and other parameters from RRF. Also you don't have the DIAG pins connected so you won't be able to detect stalls - but I guess you decided you don't need to.
I don't think the bootloader version should matter. However, the bootloader looks at the CPU ID and the voltage on the BOARD_TYPE pin to decide what board it is, and from that which CAN port to use, which pins the CAN_RESET jumper is connected to, which pins the LEDs are connected to, what default CAN address to use, and what firmware filename to ask the main board for. See the bootloader source code for details.

HTH David

wayneosdias

@dc42
1, point taken and thank you for the heads up.
2, yes this is by design
3, I presumed as much, thanks for confirming as I was having trouble following the revs to understand the relationship

I finally got a blank chip flashed and running w the bootloader and able to tie into the Duet CAN system. The issue was improper fuse setting. To fix I simply set the USER_WORD_x fuses as I read from the OE 1HCL chip;

USER_WORD_0 = 0xFE9AE239 (valid)
USER_WORD_1 = 0xAEECFFB1 (valid)
USER_WORD_2 = 0xFFFFFFFF (valid)

This is good because I can now debug on the bread board which I can't do in circuit. I proceeded to order my untested circuit because I couldn't get the bootloader to work on the breadboard. I thought this was because the chip carriers got don't have a provision for the bottom solder pad. I assumed that pad was an essential ground that when missing was causing all of my problems. Fortunately not the case.

Thanks for the help David!