# VIENNA_boardState Variable Mystery - Analysis

## The Problem

You're seeing `VIENNA_boardState = 5` in the watch window, but the `VIENNA_boardState_enum` only defines values 0-2:

```c
enum VIENNA_boardState_enum {
    PowerStageOFF = 0,
    PowerStageON = 1,
    TripCondition = 2,
};
```

## Root Cause Identified

**The issue is that `VIENNA_boardState` is being assigned the value of `VIENNA_buildInfo` at runtime, NOT a value from the `VIENNA_boardState_enum`.**

### Evidence:

There are **TWO separate enums** defined in `vienna.h`:

```c
enum VIENNA_boardState_enum {
    PowerStageOFF = 0,
    PowerStageON = 1,
    TripCondition = 2,
};

enum VIENNA_BuildLevel_enum {
    BuildLevel_1_OpenLoop = 0,
    BuildLevel_2_CurrentLoop = 1,
    BuildLevel_3_VoltageAndCurrentLoop = 2,
    BuildLevel_4_BalanceVoltageAndCurrentLoop = 3,
    BuildLevel_1_OpenLoop_CLA = 4,           // ← VALUE = 5 IS HERE!
    BuildLevel_2_CurrentLoop_CLA = 5,        // ← 5 = This value
    BuildLevel_3_VoltageAndCurrentLoop_CLA = 6,
    BuildLevel_4_BalanceVoltageAndCurrentLoop_CLA = 7,
};
```

**Your value of 5 corresponds to `BuildLevel_2_CurrentLoop_CLA`** from the second enum!

## How It Gets Set

In `vienna.c` line 168-170:

```c
enum VIENNA_BuildLevel_enum VIENNA_buildInfo = BuildLevel_1_OpenLoop ;
enum VIENNA_boardState_enum VIENNA_boardState = PowerStageOFF;
enum VIENNA_boardStatus_enum VIENNA_boardStatus = boardStatus_Idle;
```

Then in the `VIENNA_updateBoardStatus()` function (lines 218-245), `VIENNA_buildInfo` is updated based on `VIENNA_INCR_BUILD` configuration:

```c
void VIENNA_updateBoardStatus(void)
{
#if VIENNA_INCR_BUILD == 1
    #if VIENNA_CONTROL_RUNNING_ON == C28x_CORE
        VIENNA_buildInfo = BuildLevel_1_OpenLoop;
    #else
        VIENNA_buildInfo = BuildLevel_1_OpenLoop_CLA;   // ← Value = 4
    #endif
#elif VIENNA_INCR_BUILD == 2
    #if VIENNA_CONTROL_RUNNING_ON == C28x_CORE
        VIENNA_buildInfo = BuildLevel_2_CurrentLoop;
    #else
        VIENNA_buildInfo = BuildLevel_2_CurrentLoop_CLA;  // ← Value = 5
    #endif
    // ... more cases
#endif
}
```

## The Real Problem

**Type casting or memory overlap issue:**

The watch window is showing `VIENNA_boardState` with a value that belongs to the `VIENNA_BuildLevel_enum`. This suggests:

1. **They may be sharing memory** - Either through direct assignment or a pointer being used incorrectly
2. **The debugger may be confused** about which enum type is which
3. **OR `VIENNA_buildInfo` is being written to the memory location of `VIENNA_boardState`** somewhere

### Possible Scenarios:

#### Scenario A: Direct Assignment (Most Likely)
Somewhere in your code (possibly in an ISR or background task not shown), there might be:

```c
VIENNA_boardState = (enum VIENNA_boardState_enum)VIENNA_buildInfo;  
// This would assign 5 from VIENNA_buildInfo to VIENNA_boardState
```

#### Scenario B: Shared Union
The variables might be overlapping in a struct/union:

```c
typedef union {
    enum VIENNA_boardState_enum state;
    enum VIENNA_BuildLevel_enum buildLevel;
} VIENNA_StateUnion;
```

#### Scenario C: Debugger Display Bug
The watch window is showing `VIENNA_buildInfo`'s value but displaying it under the `VIENNA_boardState` variable label.

## How to Find the Real Assignment

**Search your entire codebase for:**

1. **Any assignment to boardState at runtime:**
   ```bash
   grep -rn "boardState\s*=" --include="*.c" --include="*.h"
   ```

2. **Any casting of buildInfo to boardState:**
   ```bash
   grep -rn "boardState.*buildInfo\|buildInfo.*boardState" --include="*.c"
   ```

3. **Any pointer dereference near boardState:**
   ```bash
   grep -rn "\*.*boardState\|&.*boardState" --include="*.c"
   ```

4. **Check all ISR files** - The update might happen in an interrupt handler
   ```bash
   find . -name "*isr*" -o -name "*interrupt*" | xargs grep "boardState"
   ```

5. **Check CLA task files** - If running on CLA:
   ```bash
   find . -name "*.cla" -o -name "*CLA*" | xargs grep "boardState"
   ```

## Solution

**Add explicit assignment tracking:**

```c
// In your main loop or debug section, add:
volatile uint16_t VIENNA_boardState_tracker;

// Periodic logging:
void logBoardState(void) {
    // This will help you track when and how boardState changes
    if (VIENNA_boardState != VIENNA_boardState_tracker) {
        // State changed!
        // Add breakpoint here or log the change
        VIENNA_boardState_tracker = VIENNA_boardState;
        // Log: new value, caller, timestamp, etc.
    }
}
```

Or use a **hardware breakpoint** on the `VIENNA_boardState` variable in CCS:
- Right-click → Set Breakpoint → Set Hardware Breakpoint on Write

## Summary

| Finding | Value |
|---------|-------|
| `VIENNA_boardState` current value | 5 |
| Enum `VIENNA_boardState_enum` range | 0-2 |
| Enum `VIENNA_BuildLevel_enum` range | 0-7 |
| Value 5 matches | `BuildLevel_2_CurrentLoop_CLA` |
| Root cause | `VIENNA_buildInfo` value being read/assigned to `VIENNA_boardState` |

**Your code is running BuildLevel 2 on CLA (not C28x core), and this value is somehow appearing in the boardState variable.**

---

## Files Reference

- **Variable declaration:** `C:/ti/c2000ware-digital-power-sdk/solutions/tidm_1000/source/pfc3phvienna/include/vienna.h:101-117`
- **Variable initialization:** `C:/ti/c2000ware-digital-power-sdk/solutions/tidm_1000/source/pfc3phvienna/source/vienna.c:168-172`
- **Update function:** `C:/ti/c2000ware-digital-power-sdk/solutions/tidm_1000/source/pfc3phvienna/source/vienna.c:218-245`