How can you effectively debug microprocessor programs for vehicles?

I don't know, very often you have to resort to debugging to figure out how things work in this project. :)) Very often debugging replaces documentation.))

As firmware often lacks interfaces to connect standard IDE to enable code-block-step level debugging, it is useful to create a dediated small debug-trace ring-buffer, which can capture scenario driven call-flows and data events, with necessary timestamp relatively synced with host timestamp, to easifer corelation with host events and behaviors. One important aspect of communication among team, while debugging is identifying life-cycle(start, end) of active agents (event, data, occurance). As firmwares often running next to digital and analog part of hardware, an identification for valid and invalid data, improve fault handling, recovery options for hw related intermittent or consistent failure, and influence fault tolerant architecture.

Simulator can provide up to 80% of software logic execution, particularly with algorithms. It is an effective way to verify software logic and state diagrams, as well message sequencing. This allows software development to proceed prior to the available physical hardware.

Usage of simultor for firmware development, debugging should be part of early stage project requirement engineering, scenario specific simulated input data. most of the debugging and coding error, feature-regressions can be handled through simulator based development and testing, automation.

Debugger is a good way to get access to the memory of the ECM. Memory dump could be done to compare the specific address location you're looking for and compare the expected value Also we can see whether there's a watchdog timer issue that's causing the MCU to reset every time and leading to an erroneous dump.

I agree logic analyzer is one good option for non intrusive debugging. I'm only talking about audio SoC based ECUs projects here. These days A2B is increasingly being used, one can rely on A2B trace to capture the trace and analyze it. You can also use a custom A2B set up where in you can make an external A2B master to pump in your test vectors and collect the pass through data for more post analysis. This sort of approach certainly help while tuning your audio algorithms whether entertainment audio use cases or noise management use cases.

A test harness mimicking vehicle's ECU set up is a great way to debug, root cause embedded software issues and also difficult to reproduce crashes or timing issues. IHVs usually have this sort of set up, so writing your test scenarios for every use case, is a good place to start and then we can automate it, or even you can roll out automation test setup using docker (container) workspace to alleviate the burden on your team members and make these efforts focus on actual software or hardware issues instead of wasting team's energy on set up related domain expertise.

Due to memory limitation on more of the firmware, some of good coding practices to improve readability start showing cracks over time, and through code-review is nagivate such code, help identify issues sooner.