CANBUS log reading

[Tazzi]

agreed. I'm not interested in PCM flasher's kernel per se, more like in any kind of E38/E67/T43 kernel as an example of best practices on how reading and writing of the flash memory is done.

Everything related to reading and writing the flash is dependent on the kernel itself that is being used.

Even though the factory kernels are suppose to follow a specific formatting, they do differ between various ecus.
This can be the difference between use 1,2,3 or 4 bytes for a mode 34, or if the mode 36 uses a fixed address or incrementing address.

Aftermarket kernels follow any formatting they choose to. Its really up to the dev to what they prefer.

Most aftermarket tools that use a custom kernel are written in assembly, theres only a couple out there which are written in C

[fastboatster]

agreed. I'm not interested in PCM flasher's kernel per se, more like in any kind of E38/E67/T43 kernel as an example of best practices on how reading and writing of the flash memory is done.

Everything related to reading and writing the flash is dependent on the kernel itself that is being used.

Even though the factory kernels are suppose to follow a specific formatting, they do differ between various ecus.
This can be the difference between use 1,2,3 or 4 bytes for a mode 34, or if the mode 36 uses a fixed address or incrementing address.

Aftermarket kernels follow any formatting they choose to. Its really up to the dev to what they prefer.

Most aftermarket tools that use a custom kernel are written in assembly, theres only a couple out there which are written in C

when I say best practices I talking about the implementation details like making various watchdog timers etc happy and/or disabling them, and potentially having the loader interrupt driven and not having an infinite loop, plus the examples of flash erase/write code for different external flash memory chips. Communication protocol is not important, I wouldn't bother to implement an ISO/SAE-compliant protocol.

[Tazzi]

when I say best practices I talking about the implementation details like making various watchdog timers etc happy and/or disabling them, and potentially having the loader interrupt driven and not having an infinite loop, plus the examples of flash erase/write code for different external flash memory chips. Communication protocol is not important, I wouldn't bother to implement an ISO/SAE-compliant protocol.

I have been down this road many times (And still do) so I can comment quite confidently about this.

There are a few parts with ECUs (or any module) that must be satisfied:

1) Need to disable all interrupts running on the CPU, otherwise this will result in random reboots or ram corruption when running a kernel.
Some CPUs will also trigger interrupts when attempting to access flash (both internal and external) so this also causes a reboot if they are not disabled.

2) After disabling interrupts, either a new interrupt must be created on a timer to perform the watchdog reset, or it must be manually polled to reset. Ontop of this, any internal components such as a slave CPU that require a notification/acknowledgment message must also be dealt with, this is typically via SPI and must be run periodically to prevent the main CPU from being reset (perfect example is a E38/E67).

3) All code for identifying, erasing and writing to external flash chips are on the flashchips datasheet. Off the top of my head, the E38 uses an AMD flash, and the E67 uses a spansion, I have alot of this information in a thread where I was doing the bootloader/kernel development on pcmhacking

4) Typically the main loop is always waiting for a new CAN frame to come in to process and respond to the requested command.
An interrupt can be setup to trigger an event to read the CAN frame out into a buffer, but I still have a main infinite loop that waits until it sees a new message in the queue to begin processing.

5) ECUs that use internal flash require quite a deep understand of how the memory is allocated and protected. Basically there is a memory management unit that has to be controlled, including allowing read/write access to internal flash, along with unlocking sectors which may be password protected to allow erasing and writing. So long as you follow the recommended templates shown in the reference manuals, it is fairly straight forward (Although, I can admit to killing a couple ECUs every so often during development).

[fastboatster]

thank you, you brought a lot of good points! I'll check out your e38/e67 thread, sounds like it will be very useful