Skip to main content
This guide covers testing procedures for validating BlueBus firmware changes, from component-level testing to full vehicle integration.

​
Testing philosophy

BlueBus firmware testing combines multiple approaches:
  • Simulator testing - Initial verification using MPLAB X Simulator
  • Bench testing - Hardware validation without vehicle integration
  • Vehicle testing - Full integration testing in supported BMW models
  • Regression testing - Ensuring existing functionality remains intact
Due to the embedded nature of the BlueBus and its tight integration with vehicle systems, comprehensive testing requires access to a compatible BMW vehicle with I-Bus.

​
Pre-flight checks

Before flashing new firmware to hardware, perform these basic validations:
1

Verify compilation

Ensure the firmware builds without errors or warnings:
cd firmware/application
make clean
make build
The build should complete with:
BUILD SUCCESSFUL (total time: Xs)
Enable maximum warnings in your build configuration to catch potential issues early. The project is configured with enable-all-warnings and enable-fatal-warnings.
2

Check memory usage

Review the memory usage report in the build output:
Program Memory  : 85432 bytes   (7.9% Full)
Data Memory     : 8192 bytes    (50.0% Full)
Ensure:
  • Program memory usage < 90% (< 0xAA800 for bootloader compatibility)
  • Data memory usage < 80% (leaving headroom for stack)
3

Review code changes

Use static analysis tools or manual review to check:
  • No uninitialized variables
  • No buffer overflows in string operations
  • Proper bounds checking on arrays
  • Correct interrupt handling (no long-running operations in ISRs)
  • Proper use of volatile for hardware registers and ISR-modified variables

​
Simulator testing

MPLAB X includes a simulator for testing firmware without hardware:

​
Setting up the simulator

  1. In MPLAB X, right-click your project and select Properties
  2. Under Hardware Tool, select Simulator
  3. Click OK

​
Running in simulator

  1. Set breakpoints in your code by clicking the line number margin
  2. Click Debug Project (Ctrl+F5)
  3. Use the Debug toolbar to:
    • Step Over (F8) - Execute one line at a time
    • Step Into (F7) - Step into function calls
    • Continue (F5) - Run until next breakpoint

​
Simulator limitations

The simulator cannot emulate:
  • UART communication (I-Bus, Bluetooth, USB)
  • I2C peripherals (WM8804, PCM5122)
  • Real-time timing constraints
  • Interrupt interactions with external devices
Use simulator testing primarily for validating logic flow and algorithm correctness.

​
Bench testing

Bench testing validates hardware functionality outside of a vehicle:

​
Required equipment

  • BlueBus hardware (v1.x or v2.x)
  • 12V power supply (2A minimum)
  • USB cable for serial monitoring
  • Logic analyzer or oscilloscope (optional but recommended)
  • PICkit 3/4 for debugging

​
Serial console testing

The BlueBus exposes a CLI over the system UART at 115200 baud: 
screen /dev/ttyUSB0 115200
After connecting, you should see: 
**** BlueBus ****
Type help to see available commands: 
Available commands:
  help     - Display this help message
  version  - Display firmware version
  status   - Display system status
  reset    - Reset the device
  bt       - Bluetooth module commands
  config   - Configuration commands

​
Testing I-Bus communication

Without a vehicle, you can test I-Bus packet handling:
  1. Connect a second microcontroller or UART adapter to simulate I-Bus traffic
  2. Send valid I-Bus packets (see lib/ibus.h for packet format)
  3. Monitor the BlueBus response with a logic analyzer
Example I-Bus packet (CD Changer status poll): 
Source: 0x68 (Radio)
Length: 0x03
Dest:   0x18 (CDC/BlueBus)
Cmd:    0x38 (CDC Request)
Data:   0x00 (Get Status)
Checksum: XOR of all bytes

​
Testing Bluetooth module

The BM83 Bluetooth module can be tested independently:
  1. Use the CLI bt command to query module status: 
    bt status
bt pair
bt disconnect
  2. Monitor UART communication between PIC and BM83 on UART2
  3. Verify Bluetooth pairing and audio streaming with a phone
The BM83 communicates at 115200 baud using a proprietary binary protocol. See lib/bt/bt_bm83.h for command definitions.

​
Vehicle testing

Full vehicle testing validates integration with BMW I-Bus systems:

​
Test vehicle requirements

  • BMW E38, E39, E46, E53, E83, E85/E86, or MINI R50/R52/R53
  • I-Bus equipped (navigation or non-navigation)
  • Display unit: BMBT, MID, CD53, or MIR

​
Installation for testing

  1. Locate the CD changer connector in the trunk or glovebox
  2. Connect BlueBus to the 10-pin CD changer harness:
    • Pin 1: Ground
    • Pin 3: I-Bus
    • Pin 7: +12V
  3. Connect USB cable to the BlueBus for serial monitoring (optional)
Always test with ignition in position 2 (accessories on). Never install or remove modules with the ignition on.

​
Core functionality tests

Perform these tests for every firmware release:

​
Audio streaming

1

Pair a Bluetooth device

  • Press and hold the BlueBus pairing button (or use vehicle menu)
  • Pair a smartphone via Bluetooth
  • Verify the telephone LED turns green when connected
2

Test audio playback

  • Press CD button on the radio
  • Start music playback on the phone
  • Verify:
    • Audio plays through vehicle speakers
    • Metadata displays on screen (artist, title, album)
    • Volume control works via steering wheel/radio
3

Test playback control

  • Use steering wheel or radio buttons to:
    • Pause/play
    • Next/previous track
    • Fast forward/rewind
  • Verify the phone responds to all commands

​
Hands-free telephony

1

Receive a call

  • Have someone call your paired phone
  • Verify:
    • Caller ID displays on vehicle screen
    • Audio mutes and ring tone plays
    • Telephone LED turns red
2

Answer the call

  • Press the telephone button on steering wheel
  • Verify:
    • Call audio routes through speakers
    • Microphone captures your voice
    • Vehicle controls (end call, mute) work
3

Make an outbound call

  • Activate Siri/Google Assistant via steering wheel
  • Request a call via voice command
  • Verify call establishment and audio routing

​
Vehicle integration

1

Test on-board computer

  • Navigate to OBC on the instrument cluster
  • Verify BlueBus displays:
    • Coolant temperature
    • Ambient temperature
    • Oil temperature (if available)
2

Test configuration menu

  • Access BlueBus settings via vehicle display:
    • Audio settings (DAC gain, DSP input)
    • Telephony settings (HFP mode, mic gain)
    • Comfort features (auto-lock, blinker count)
    • UI settings (language, temperature units)
  • Change settings and verify they persist after ignition cycle
3

Test comfort features

  • Auto-lock: Drive above configured speed threshold, verify doors lock
  • Auto-unlock: Turn ignition off, verify doors unlock
  • Comfort signals: Tap turn signal stalk, verify configurable blink count

​
Display unit compatibility

Test with all available display types:
DisplayResolutionTest Focus
BMBTGraphicalFull menus, metadata, graphics
MID24 charsSingle-line scrolling text
CD5311 charsLimited text display
MIRSingle lineBasic metadata

​
Logging and diagnostics

Use the serial console to monitor system behavior during vehicle tests: 
python3 utility/log_parser.pl > test_log.txt
The log will show:
  • I-Bus packet traffic
  • Bluetooth module events
  • Configuration changes
  • Error conditions

​
Regression testing

Before releasing firmware, verify all core features still work:

​
Regression checklist

  • Bluetooth pairing and connection
  • Audio playback (A2DP)
  • Metadata display (AVRCP)
  • Playback control (play, pause, next, previous)
  • Incoming call handling
  • Outgoing call via voice assistant
  • Caller ID display
  • Microphone audio quality
  • On-board computer data
  • Configuration menu access
  • Setting persistence across power cycles
  • Auto-lock/unlock (if enabled)
  • Comfort turn signals (if enabled)
  • Multi-language support
  • Firmware upgrade via USB

​
Board version testing

Test on both hardware revisions:
  • v1.x - WM8804 S/PDIF receiver
  • v2.x - DIT4096 S/PDIF transmitter
Key differences: 
if (boardVersion == BOARD_VERSION_ONE) {
    WM88XXInit();  // v1.x only
} else if (boardVersion == BOARD_VERSION_TWO) {
    SPDIF_RST = 1; // v2.x only
}

​
Continuous integration

While BlueBus doesn’t have automated CI/CD due to hardware requirements, maintain good practices:
  1. Document all changes in commit messages
  2. Create test reports for vehicle validation
  3. Track issues in GitHub Issues
  4. Version tagging for releases: 
    git tag -a v1.2.3 -m "Release version 1.2.3"
git push origin v1.2.3

​
Reporting issues

When reporting bugs or test failures, include:
  1. Firmware version (version command output)
  2. Hardware version (v1.x or v2.x)
  3. Vehicle details (model, year, display type)
  4. Steps to reproduce the issue
  5. Serial console log (if applicable)
  6. Expected vs. actual behavior

​
Safety considerations

Always prioritize vehicle and occupant safety:
  • Never test while driving
  • Ensure critical vehicle functions (lights, HVAC) still work
  • Test auto-lock/unlock in a safe environment
  • Verify telephone functionality doesn’t interfere with driving
  • Keep original BMW equipment available in case of issues

​
Next steps

After validating your changes:
  • Review the code style guide to ensure compliance
  • Create a pull request with detailed test results
  • Include vehicle test logs and validation screenshots
  • Request review from project maintainers

Build docs developers (and LLMs) love

Get started for freeTalk to us