How hard is CAN?

[Rudolph Riedel]

it only has 10kiB of dedicated SRAM for two modules combined. So mostly the same but not really.

IMHO, 10KB is a lot for such low-speed interface (CAN FD around ~5Mbps max), even if part of it is "wasted" on filter configuration and not actual FIFOs. At some point, you have to process the data anyway. The flexibility in H7 is great because you can exactly decide how many (1 or 2) and large FIFOs and fixed mailboxes, if any, are used, so nothing of that 10KB is wasted.

The thing is, one fully configured unit needs 17kiB, that is 128 11-bit filters (128 words), 64 29 bit filters (128 words), two RX FIFOs with 64 Elements for 64 byte messages (1152 words each), 64 RX buffers (1152 words), 32 element TX Event FIFO (64 words) and 32 TX buffers (576 words).
Yes, you do not need all of this, but you are limited when you only have 10kiB to use for two units.
2 Units, 1 full RX FIFO each (1152 words), 10 TX buffers each (180 words), 16 filter elements each (32 words) - 10912 bytes - oops.
If you have full domain over the memory like with the ATSAME51 you can just setup whatever you need and reduce it a little if you are running low on memory overall. And if you are not using the CAN units they do not use any memory.
With the H7 you have to put more planning into your application.

[peter-h]

The thing is, one fully configured unit needs 17kiB, that is 128 11-bit filters (128 words), 64 29 bit filters (128 words), two RX FIFOs with 64 Elements for 64 byte messages (1152 words each), 64 RX buffers (1152 words), 32 element TX Event FIFO (64 words) and 32 TX buffers (576 words).

Could someone please explain what this means? 128 11-bit filters?

[uer166]

The thing is, one fully configured unit needs 17kiB, that is 128 11-bit filters (128 words), 64 29 bit filters (128 words), two RX FIFOs with 64 Elements for 64 byte messages (1152 words each), 64 RX buffers (1152 words), 32 element TX Event FIFO (64 words) and 32 TX buffers (576 words).

Could someone please explain what this means? 128 11-bit filters?

Normal CAN IDs are 11-bits. When you send a message, it has that associated ID. Some nodes on the bus care about that message, others don't. CAN peripherals provide a way to only accept frames with the IDs you care about to minimize software loading. I.e. the bus could be full of crap you don't care, but you'll only get CAN messages in the mailbox that you care about via those filters.

In that example, the peripheral can do 128 of those 11-bit ID filters.

[nctnico]

The thing is, one fully configured unit needs 17kiB, that is 128 11-bit filters (128 words), 64 29 bit filters (128 words), two RX FIFOs with 64 Elements for 64 byte messages (1152 words each), 64 RX buffers (1152 words), 32 element TX Event FIFO (64 words) and 32 TX buffers (576 words).

Could someone please explain what this means? 128 11-bit filters?

Normal CAN IDs are 11-bits. When you send a message, it has that associated ID. Some nodes on the bus care about that message, others don't. CAN peripherals provide a way to only accept frames with the IDs you care about to minimize software loading. I.e. the bus could be full of crap you don't care, but you'll only get CAN messages in the mailbox that you care about via those filters.

In that example, the peripheral can do 128 of those 11-bit ID filters.

AFAIK the filters can use masks so you can also filter ranges of IDs (at least this works on an STM32F1x chip I'm working with at the moment). So receiving CAN IDs 0x100 to 0x10F takes one filter where the last 4 bits are marked as 'don't care'.

[uer166]

AFAIK the filters can use masks so you can also filter ranges of IDs. So receiving CAN IDs 0x100 to 0x10F takes one filter where the last 4 bits are marked as 'don't care'.

Yup, there's different kinds of acceptance filters, but it's a IP implementation more or less. I've seen even more granular ranges, dual filters, etc. It can get pretty complicated pretty quickly.

[DiTBho]

Found qty=3 Axi-Coldfire-v1 with a built-in CAN.
Little nice boards, 20 euro each, brand new.

I just need to understand how to
- wire them into a CAN network(1)
- write a simple application

Next weeks ... 


(1) I don't know if the PHY is already on the board or if I have to add it.
The MPU has built-in CAN support but CAN PHY should be added externally,  I have to check the schematic

[Siwastaja]

The thing is, one fully configured unit needs 17kiB, that is 128 11-bit filters (128 words), 64 29 bit filters (128 words), two RX FIFOs with 64 Elements for 64 byte messages (1152 words each), 64 RX buffers (1152 words), 32 element TX Event FIFO (64 words) and 32 TX buffers (576 words).

Could someone please explain what this means? 128 11-bit filters?

This particular (quite advanced) CAN peripheral works like this:

(an example:)
* Create an acceptance filter so that message IDs between 123 ... 456 are put in RX FIFO 0
* Create an acceptance filter so that message IDs between 0 .. 10 are put in RX FIFO 1, plus interrupt is also generated
* Create an acceptance filter so that message IDs where ID & mask == mask, store into a buffer (not FIFO) and generate an interrupt

... and you can have 128 of these configurations. I don't think I have ever needed more than... five or so? The fact STM32H7 "only" has 10KB of dedicated CAN RAM means you have to choose how much of that memory you dedicate for such configuration, and how much to the actual message FIFOs / buffers. You can configure it pretty freely.

And having a powerful CPU and a fundamentally slow bus like CAN, you can always choose to just receive messages and ignore them in software.

But such hardware ability is of course great to have at your disposal.

[Siwastaja]

Attached is the simple spreadsheet I use to configure the STM32H7 FDCAN memory layout. Checks if everything fits, and works as a code generator, too.

[DavidAlfa]

I've been trying to not say it, but it's a pretty complex protocol, almost CAN't 

[ataradov]

The protocol is pretty simple. The controllers are complex because implementers decided to make them this way. There is absolutely no need for this complexity and modern MCUs can easily handle CAN traffic with minimal hardware processing. And thankfully controllers do have "simple" mode where you don't need to think about any of this.

[Siwastaja]

It's some kind of tradition to offer very powerful HW features in CAN peripherals. It kind-of made sense when you used say 8-bit AT90CAN128 MCU or similar. Funnily, as the MCU processing power went up and HW acceleration features could have gone down, they didn't, instead we have most advanced HW acceleration features ever, in a low-bandwidth bus, coupled with a high-performance CPU.

CAN itself is simpler than sliced bread, especially when you need a common bus - subscription model where messages are not very long so that it's a natural fit.

If you need to construct longer datagrams out of several CAN frames, then it's obviously some amount of work, but so is UART which hardware-delimits to 8 bits. CAN's 64-bit payload is 8x better than that, plus especially 29-bit IDs allow you to do both node addressing and data content description very simply, which in UART would require a few bytes of header and a software state machine to deal with all that. So CAN is very easy.


But even advanced controllers are not usually that difficult to use. Just instead of
isr_received_message()
{
    message = fifo_pop();
    if(message.id == 123)
        // do the thing
    else
       // ignore message
}

you can:
isr_received_message()
{
    message = fifo_pop();
    // do the thing
}

and
init()
{
    // configure acceptance filter for id 123, usually just a few lines of code, but of course you need to RTFM which is more work than if(id == 123)
}

[Rudolph Riedel]

The CAN module in the AT90CAN128 or ATMega16M1 was awfull, address the MoB, one data register for the message with its own "address counter".

With the M_CAN I usually do not even use an interrupt anymore, I just check the FIFO in my main loop if something arrived between two time-slices.
This even works with protocolls like ISO-TP since messages do not need to be answered immediately.

[HwAoRrDk]

The CAN module in the AT90CAN128 or ATMega16M1 was awfull, address the MoB, one data register for the message with its own "address counter".

The whole MOB paging thing wasn't too bad, just an inconvenience - at least I thought so.

But the CAN peripheral could have been much better documented. To the extent that the best documentation for it is a guide written by some random guy posted on avrfreaks.net. I copied it and put it in a nicely-formatted PDF to save for future reference in case it disappears someday.

[Siwastaja]

With the M_CAN I usually do not even use an interrupt anymore, I just check the FIFO in my main loop if something arrived between two time-slices.

This works pretty decently because the slow speed of CAN and large amount of overhead limits the maximum message rate to a predetermined value; even with CAN FD, the arbitration part is still at 1MBPS at most and takes a lot of time per message.

So even with a 1-element buffer this would be doable (like with simple controllers); having a FIFO capable of holding tens of messages makes it even more trivial and forgiving.

The great thing in M_CAN is, you can configure some specific filter to put the message in different FIFO (or not put it anywhere) and generate an interrupt for that message only, without having to interrupt the system for the bulk of messages. I have been using this as a very foolproof control interface allowing device reset and firmware update. By being the highest priority interrupt in the system, the CAN flasher always Just Works even in presence of bugs hanging the system otherwise.

But indeed, mostly I just pop everything from the RX FIFO in some repetitive handler, too. If you can prove the handler runs at some certain interval, it is easy to further prove the FIFO never gets full.

[Rudolph Riedel]

The CAN module in the AT90CAN128 or ATMega16M1 was awfull, address the MoB, one data register for the message with its own "address counter".

The whole MOB paging thing wasn't too bad, just an inconvenience - at least I thought so.

Well, awfull in comparision, I don't even know anymore when I implemented the code for the 90CAN128 CAN-controller from the datasheet, must been like 15+ years ago. And then I mostly used the same code for a decade or so, slightly reduced with the 16M1 since it has fewer MoBs.
Well, this was AVR and the unit was copied over from some 8051 design I believe.
It sure did the job.

But the CAN peripheral could have been much better documented. To the extent that the best documentation for it is a guide written by some random guy posted on avrfreaks.net. I copied it and put it in a nicely-formatted PDF to save for future reference in case it disappears someday.

That would have been nice to find something like this. :-)

[HwAoRrDk]

That would have been nice to find something like this. :-)

I found it again, the forum thread is still there:
https://www.avrfreaks.net/forum/tut-using-8-bit-avr-controller-area-network-can-register

[peter-h]

The 32F4 has a firmware boot loader which has a CAN option. Has anyone tried to make it work? I read somewhere that the implementation is particularly difficult to use.

Maybe if the product has a CAN interface only then CAN boot loading is a good idea, otherwise anything else should be easier - like RS232

[Rudolph Riedel]

This one?
https://www.st.com/resource/en/application_note/an3154-can-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf

I really hope that I am reading this wrong, is this bootloader really using CAN-Identifiers for command codes?
If yes - what the heck? XCP for example is around for almost 20 years now (and even a lot longer as CCP).

[Siwastaja]

Even funnier is the CAN bootloader in STM32H7.

They had to completely re-design the protocol just for the sake it to prevent anything existing from working.

Additionally, they just had to make it CAN FD only. No fallback to standard CAN. One could imagine it would be obvious to be able to use standard CAN frames, and additionally use CAN FD frames if faster firmware upload is required - usually it isn't.

A total joke.

[peter-h]

So, how would one load firmware into a 32F4 via CAN? I don't mean build your own programmer with another 32F4

[Rudolph Riedel]

Look for a CAN bootloader and flash it with the debugger?

Yes, sorry, easier said than done and I have the luxury that a proprietary XCP bootloader kind of fell into my hands a couple of years ago.
And a flash tool that works with Vector USB/CAN interfaces.

[Siwastaja]

So, how would one load firmware into a 32F4 via CAN? I don't mean build your own programmer with another 32F4

Get a USB-CAN interface (popular examples: Kvaser, PCAN; world is also literally full of cheap DIY CAN adapter projects you can buy from their designers) and
A) try to find some stm32 CAN bootloader flasher software that supports the CAN bootloader protocol used by the 32F4,
B) if you can't find that, read the documentation of the bootloader and write the tool yourself.

USB-CAN interfaces are a total CAN (pun intended) of worms on their own; on linux, no problem at all since the interface is standardized (see SocketCAN) and thus, same application software works with any USB-CAN interface; in worst case, you may have to install a thing called driver (wow, what a great idea everybody understood, at latest, in the 1990's: provide one common interface plus a separate driver layer!).

... except Microsoft; on Windows, total disaster because it's back to early 1990's (remember how every DOS game implemented their own drivers for each sound card?), so you have to write your application code to target one specific brand of USB-CAN interface; or a wrapper layer if you want to support multiple adapters. Luckily the interfaces are usually very simple because, as discussed, CAN itself is very simple.

[peter-h]

I wonder if someone can help me. This may be trivial, or not... I am happy to make a donation to someone

I have a 32F417 driving a L9616 interface chip, whose C_H and C_L pins come out on a terminal block.

This is purely a future option in the board I am working on, and no "driver" is being done unless somebody needs CAN, but I would like to detect whether that option (the L9616 chip) has been fitted, and check that the CPU-L9616 connection works.

What is the absolute minimum amount of code which will do this?

I think the L9616 is like a 2-wire RS485 transceiver, in which case it will loop everything back to itself, but if it disables RX during TX then nothing will come back and it can't be detected. The block diagram suggests that everything on the pins is always received



but there is some gating of the transmitter from the RX data. The ASC pin on driven from a GPIO, PC13.

TXI and RXO are driven from PD1 and PD0 pins which are the default ones for the 32F4 CAN bus controller. Currently these are inputs, but it may be that once one selects the CAN controller, these pins get automatically initialised as required by that. Some 32F4 pins work that way; some don't and need to be set up.

It may not be possible to tell if the chip is an L9616 or some other RS485 chip... Not much can be done about that!

It may also be possible to test for this chip without using the CAN controller at all, just by bit-banging the two GPIO pins PD1,PD0. Not ideal, perhaps.

I am using Cube IDE.

Many thanks in advance

[Berni]

Yep the easiest way to test is to simply toggle IO pin connected to TXO at a rate of about 1 to 1000kHz. Apply a CAN terminator on the CAN bus pins then poke them with an oscilloscope and you should see the typical CAN voltage levels. At the same time the RXO pin should be toggling in sync with how you drive TXO. The RX1 and ASC pins can be left unconnected.

If you want to actually send communication over it then you can try initializing a UART on TXO and RXO. Anythyng you send out should appear on the bus and you should receive it back into the UART (since CAN is always listening on the bus, even when transmitting)

[Doctorandus_P]

While the data in CAN frames used in the automotive industry is mostly undocumented, CAN is also used in "industry" for things like frequency inverters and servo motor controllers. There are also a bunch of completely Open Source implementations of closed loop stepper motors that use CAN. It may be a good starting point to get to know CAN. If you're not into motors, there are probably lots of other open source projects (including libraries) that use CAN in some way. Studying a working applictation is usually a lot easier then trying to build something from scratch yourself.