Hi, I was wondering if I can use Standar CAN 2.0B with the FDCAN controller integrated in STM32G474RE Nucleo Board. Is there any way to adjust the baud rate to a specific value with these drivers? Like 500 kHz bit rate? If im not wrong, the driver just allows to enable or disable FD format but not to change de baud rate.
Thank you.
[DEV] STM32G4xx support
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [DEV] STM32G4xx support
Hi,
The driver in ChibiOS is not yet complete but the FDCAN peripheral should be able to use regular CAN frames.
Giovanni
The driver in ChibiOS is not yet complete but the FDCAN peripheral should be able to use regular CAN frames.
Giovanni
Re: [DEV] STM32G4xx support
Stapelzeiger wrote:Hi,
what is the status of the FDCAN driver? It looks like @Shevchenko last fix is not in the repo.
With @Shevchenko's change it works on my G474 Nucleo, but I can't get it to work on a custom board with an H743ZI. I can see a change from recessive to dominant on the output with a scope if I manually set FDCAN_TEST_TX to 0b10 (aka force dominant), but I can't get any real data to come out. When I had my G474 miswired, I could get errors to show up in the FDCAN_PSR register, but on the H7, nothing changes there after a transmit, and nothing happens on the output pins.
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [DEV] STM32G4xx support
There are differences between G4 and H7 FDCAN units, those differences are not addressed in the contributed driver yet.
Giovanni
Giovanni
Re: [DEV] STM32G4xx support
Giovanni wrote:There are differences between G4 and H7 FDCAN units, those differences are not addressed in the contributed driver yet.
Happen to know what those are off the top of your head? I'm happy to fix the driver for the H7, but I'm not sure what actually changed since it appears they're the same IP from Bosch (shared with a few NXP and Infineon parts too!).
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [DEV] STM32G4xx support
The organization of RAM is also different.
The driver in repository tries to address that but it is not complete.
Giovanni
The driver in repository tries to address that but it is not complete.
Giovanni
Re: [DEV] STM32G4xx support
Ok - I've managed to get both transmission and reception working on the H7. Really the only difference is that on the G4, the memory layout is fixed, while on the H7 it's fully configurable (and has no defaults set).
Adding this section before the comment "Going in active mode" near line 295 correctly configures the memory layout:
The other problem is that the defaults in the registry are actually an impossible combination: the reference manual advertises a range of elements for each of the buffers, but using the maximum on all at the same time will require more memory than the 10KB available.
The registry section can be changed to:
These sizes are a reasonable balance. Features not supported by the driver are disabled (ie, 0 size buffer), and the others are essentially as large as possible without overflow.
There were also a few bugs in the init sequence of the driver, and I've fixed those too here: https://github.com/ChibiOS/ChibiOS/pull/38/files (yes, I know github is a mirror, but it also has a nice diff viewer that isn't a forum).
With these changes it seems to work great on my custom H7 board - I tested both RX and TX FIFO behavior, and both work as expected. Up to 56 frames can get queued per mailbox for RX, and 32 frames queued for TX. I hooked up two devices and had them blast messages back and forth, and it's so far missed zero frames after running with the bus saturated for a few hours.
Adding this section before the comment "Going in active mode" near line 295 correctly configures the memory layout:
Code: Select all
#ifdef STM32H7XX
/* H7 version of FDCAN has configurable memory layout, so configure it */
canp->fdcan->SIDFC = STM32_FDCAN_FLS_NBR << 16 | SRAMCAN_FLSSA;
canp->fdcan->XIDFC = STM32_FDCAN_FLE_NBR << 16 | SRAMCAN_FLESA;
canp->fdcan->RXF0C = STM32_FDCAN_RF0_NBR << 16 | SRAMCAN_RF0SA;
canp->fdcan->RXF1C = STM32_FDCAN_RF1_NBR << 16 | SRAMCAN_RF1SA;
canp->fdcan->RXBC = SRAMCAN_RBSA;
canp->fdcan->TXEFC = STM32_FDCAN_TEF_NBR << 16 | SRAMCAN_TEFSA;
/* NB: this doesn't set NDTB, but sets TFQS to run in queue mode with no dedicated buffers */
canp->fdcan->TXBC = STM32_FDCAN_TB_NBR << 24 | SRAMCAN_TBSA;
/* set to use the full 18-byte size buffer elements */
canp->fdcan->TXESC = 0x007;
canp->fdcan->RXESC = 0x777;
#endif /* STM32H7XX */
The other problem is that the defaults in the registry are actually an impossible combination: the reference manual advertises a range of elements for each of the buffers, but using the maximum on all at the same time will require more memory than the 10KB available.
The registry section can be changed to:
Code: Select all
/* CAN attributes.*/
#define STM32_HAS_FDCAN1 TRUE
#define STM32_HAS_FDCAN2 TRUE
#define STM32_HAS_FDCAN3 FALSE
#define STM32_FDCAN_FLS_NBR 64U
#define STM32_FDCAN_FLE_NBR 64U
#define STM32_FDCAN_RF0_NBR 56U
#define STM32_FDCAN_RF1_NBR 56U
#define STM32_FDCAN_RB_NBR 0U
#define STM32_FDCAN_TEF_NBR 0U
#define STM32_FDCAN_TB_NBR 32U
#define STM32_FDCAN_TM_NBR 0U
These sizes are a reasonable balance. Features not supported by the driver are disabled (ie, 0 size buffer), and the others are essentially as large as possible without overflow.
There were also a few bugs in the init sequence of the driver, and I've fixed those too here: https://github.com/ChibiOS/ChibiOS/pull/38/files (yes, I know github is a mirror, but it also has a nice diff viewer that isn't a forum).
With these changes it seems to work great on my custom H7 board - I tested both RX and TX FIFO behavior, and both work as expected. Up to 56 frames can get queued per mailbox for RX, and 32 frames queued for TX. I hooked up two devices and had them blast messages back and forth, and it's so far missed zero frames after running with the bus saturated for a few hours.
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [DEV] STM32G4xx support
Hi,
Good work, could you post a patch here?
A small test loopback application would be useful too, how did you test it?
Giovanni
Good work, could you post a patch here?
A small test loopback application would be useful too, how did you test it?
Giovanni
Re: [DEV] STM32G4xx support
Giovanni wrote:Good work, could you post a patch here?
A small test loopback application would be useful too, how did you test it?
I've attached a patch to this post - let me know if that works.
I tested both with a simple loopback test app (fill the TX fifo, wait some ms for it to flush, then empty the RX FIFO), and trying the fixed driver in the full rusEFI firmware, connected to a real car communicating with other devices on the bus (gauges, sensors, etc). I've attached the tester I wrote. The mcuconf/halconf/chconf are all the same as the H743ZI nucleo 144, except with FDCAN enabled.
For fun, here's my car running a couple weeks ago on an STM32H743 (running ChibiOS!) but without CAN working: https://www.youtube.com/watch?v=Xu1WibAQU_s
- Attachments
-
- loopback.zip
- STM32H7 FDCAN loopback tester
- (13.24 KiB) Downloaded 214 times
-
- h7-fdcan.zip
- patch to fix FDCAN driver for STM32H7
- (1.4 KiB) Downloaded 216 times
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 35 guests