> However, if I leave the bus as it is, it looks like the bus from the perspective of the custom board just turns off. I can see the 3rd party ECU splurging out one of its' messages as fast as it can, however our board should be seeing this message and transmitting Acks etc.
Having dealt with i similiar problem in another system, I had to disable (or not enable) CAN at initial hardware setup, clear all "flooded" CAN FIFOs (or other hardware receive buffers), and enable the CAN peripheral only when the application was ready for reception and processing.
In my case, I dealt with a CANopen ECU, which is supposed to initiate the CAN communication on the bus. However, this use case included a non-compliant device that didn't ever shut up, and was powered on before the ECU. Thus the problem had to be solved on the (CANopen) master node, the ECU.
For the bus-off, you would need to check the bus configuration, and physical signals.
If no other node exist on the bus (or is ready), transmitting node will quickly go into passive mode. This wasn't the case in my setup, with all sort of other nodes present (CANopen sensor devices) which would acknowledge messages.
A transmitting node should never go in bus-off state on a proper bus (unless the error-passive and bus-off error level are identical, which is not the default).
