# Stellar SR6P7 — AUTOSAR Classic (ETAS Tresos) — BSW Target + Integration Plan

## 1) BSW cible (scope demandé)

### MCAL (SR6P7)
- `Mcu` (clock/reset/PLL)
- `Port` (mux/pad config)
- `Dio` (digital I/O)
- `Gpt` (general purpose timers)
- `Icu` (input capture si besoin)
- `Pwm` (si actionneurs)
- `Wdg` (watchdog HW) + `WdgIf`
- `Can` (driver CAN)
- `Fls` (Flash driver) / `Eep` si EEPROM externe, sinon `Fee`

### ECU Abstraction
- `CanTrcv` (si transceiver pilotable) + `CanIf`

### Services
- `Det` (Dev Error Tracer) — indispensable en bring-up
- `Dem` (Diagnostic Event Manager)
- `Dcm` (Diagnostic Communication Manager)
- `Com` (signals)
- `PduR` (routing)
- `CanIf` (interface) + `CanSM` (state manager)
- `CanTp` (transport layer UDS) si diag sur CAN
- `EcuM` (ECU state manager)
- `BswM` (mode manager)
- `SchM` (scheduler manager / exclusive areas)
- `NvM` (NVRAM Manager)
- `MemIf` (memory abstraction)
- `Fee` (Flash EEPROM Emulation) + `FlsIf`
- `Crc` (CRC services)

### OS
- AUTOSAR OS (Osek/AUTOSAR OS) via Tresos (tâches + alarmes)

### Recommandations d’architecture
- **Bring-up minimal** : `Mcu + Port + Dio + Gpt + Det + Os`.
- **CAN stack** (min) : `Can + CanIf + CanSM + (Com/PduR selon besoins)`.
- **Diag** : `Dcm + Dem + CanTp + CanIf + PduR`.
- **NvM** : `NvM + Fee + Fls + MemIf + Crc`.

> Remarque: la sélection exacte dépend du package MCAL/BSW livré (ETAS/tiers) pour SR6P7 et de la disponibilité des modules.

## 1bis) Découpage cible (ce que tu auras dans Tresos)

- **MCAL**: configuration des modules `Mcu/Port/Dio/Gpt/Can/Fls/...` + export du code C/H.
- **OS**: tâches, alarmes, ISRs, ressources (priorités, periods).
- **Communication**:
  - `CanIf/CanSM` (modes, controllers, transceiver)
  - `PduR` (routing)
  - `Com` (si signaux)
  - `CanTp` (si UDS)
- **Diag**: `Dcm` (services UDS) + `Dem` (événements DTC).
- **NvM**: `NvM` + `Fee/Fls/MemIf/Crc`.

## 2) Plan d’intégration (ordre recommandé)

### Phase A — Infrastructure projet
1. Toolchain + linker + startup (souvent fourni par le package SR6P7 / IDE)
2. Intégration du code généré Tresos (dossiers + includes)
3. Ajout d’un `main.c` applicatif minimal qui appelle les init BSW

**Critère OK**: build + flash sur kit, entrée dans `main()`.

### Phase B — Bring-up MCAL + OS
1. `Mcu_Init` + `Mcu_InitClock` + `Mcu_DistributePllClock` (selon MCAL)
2. `Port_Init`
3. `Dio` test (toggle LED)
4. `Gpt_Init` + test tick
5. OS: tâches + alarmes (1ms/10ms/100ms)

**Critère OK**: LED toggle en tâche 100ms, tick 1ms stable.

### Phase C — CAN de base
1. `Can_Init`
2. `CanIf_Init`
3. `CanSM_Init` + transitions (NoCom -> FullCom)
4. Test TX/RX via callback `CanIf_RxIndication`

**Critère OK**: trames reçues / envoyées, bus stable.

### Phase D — COM stack (si signaux)
1. `PduR_Init`, `Com_Init`
2. Mapping PDU -> signals
3. Cycliques: `Com_MainFunctionRx/Tx`

**Critère OK**: signaux se mettent à jour (TX périodique + RX).

### Phase E — Diag UDS
1. `Dem_Init`
2. `Dcm_Init`
3. `CanTp_Init` + `PduR_Init` routing diag
4. Périodiques: `Dcm_MainFunction`, `Dem_MainFunction`

**Critère OK**: session diag répond (ex: ReadDataByIdentifier) via outil UDS.

### Phase F — NvM
1. `Fls_Init`, `Fee_Init`, `NvM_Init`
2. Périodiques: `Fls_MainFunction`, `Fee_MainFunction`, `NvM_MainFunction`
3. Test: lecture/écriture d’un bloc NvM, reset, relecture

**Critère OK**: données persistantes après reset.

## 3) “Main functions” (tick) — exemple
- 1ms : `CanIf_MainFunctionRx/Tx` (si requis), `CanSM_MainFunction`, `CanTp_MainFunction` (selon config)
- 10ms : `Dcm_MainFunction`, `Dem_MainFunction`
- 10/100ms : `NvM_MainFunction`, `Fee_MainFunction`, `Fls_MainFunction` (souvent plus lent)
- 10ms : `Com_MainFunctionRx/Tx`

Les fréquences exactes dépendent des recommandations ETAS + config.

## 3bis) Template scheduling (OS tasks / alarms) — proposition

Objectif: éviter de tout mettre en 1ms et isoler les tâches « lourdes ».

- **Task_1ms (high prio)**
  - `CanSM_MainFunction()` (si configuré cyclique)
  - `CanIf_MainFunctionRx()` / `CanIf_MainFunctionTx()` (si requis par vendor)
  - `CanTp_MainFunction()` (si diag via CanTp)

- **Task_10ms (medium prio)**
  - `Com_MainFunctionRx()` / `Com_MainFunctionTx()`
  - `Dcm_MainFunction()`
  - `Dem_MainFunction()`

- **Task_100ms (low prio)**
  - `NvM_MainFunction()`
  - `Fee_MainFunction()`
  - `Fls_MainFunction()` (souvent si driver asynchrone)

Notes:
- La liste exacte dépend de la config Tresos + de la doc ETAS (certains modules demandent des main functions, d’autres utilisent uniquement des callbacks/ISRs).
- Si `Fls/Fee` sont « blocking », il faut éviter de les appeler dans une tâche trop fréquente.

## 4) Dossier projet
- `src/` : code applicatif (main + app)
- `include/` : headers applicatifs
- `generated/` : dépôt du code généré Tresos (à copier/mapper ici)
- `config/` : notes et exports (arxml, etc.)

## 4bis) Workflow ETAS Tresos (pratique)

### Étape 1 — Import / configuration
1. Créer un workspace Tresos + importer les **ARXML** (ou projet de base ETAS).
2. Configurer l’OS (tâches/alarmes) au plus tôt (bring-up).
3. Configurer MCAL minimal: `Mcu`, `Port`, `Dio`, `Gpt`.

### Étape 2 — Génération
1. Générer le code (BSW/MCAL/OS selon ton package).
2. Récupérer:
   - sources `.c` / headers `.h`
   - `MemMap.h` / `Compiler_Cfg.h` / `Compiler.h` (si fournis)
   - fichiers de config `*_Cfg.c/h`

### Étape 3 — Intégration dans ce scaffold
1. Copier ou référencer le code généré dans `generated/`.
2. Ajouter les include paths:
   - `generated/` + sous-dossiers vendor
3. Ajouter les sources générées au build (IDE ou script).
4. Vérifier:
   - mapping des sections (MemMap)
   - startup + vector table + linker script

### Étape 4 — Bring-up tests (avant CAN/Diag/NvM)
- Test Dio (LED)
- Test Gpt tick (mesure via oscillo ou toggles)
- Lancement OS + exécution de tâches périodiques

## 4ter) Checklist d’intégration — points critiques

- **Horloges** (`Mcu`): fréquence core/peripheral correcte avant `Port/Can`.
- **Interruptions**: catégories ISR OS vs non-OS, priorité, mapping.
- **Can**: bit timing, mapping pins, transceiver, wake-up.
- **MemMap**: sections conformes (sinon erreurs de link).
- **Main functions**: appelées au bon period (sinon timeouts diag / com / nvm).

## 5) Prochaines infos nécessaires
Pour que je rende le squelette 100% aligné, dis-moi:
- IDE/build: **STellar Studio** ? **IAR** ? **GCC** ?
- Le package MCAL/OS/BSW exact livré par ETAS pour SR6P7 (nom/version)
- Bus diag: UDS sur CAN classique ou CAN-FD ?

## 6) Objectifs de validation (milestones)

- **M1 (bring-up)**: OS up + LED toggle + tick stable
- **M2 (CAN)**: TX/RX stable sur bus
- **M3 (Diag)**: UDS répond (ReadDID / SessionControl)
- **M4 (NvM)**: write/read block + reset + relecture OK

## 7) Safety (ISO 26262) — focus ASIL D (SR6P7)

> Cette section est un **cadre générique** (mécanismes typiques et intégration BSW). Les capacités exactes (lockstep, monitors, BIST, partitions, etc.) et leur mode d’utilisation doivent être **confirmées** avec la documentation Safety du SR6P7 + ton package MCAL/BSW (ETAS/tiers).

### Objectifs ASIL D (vision système)
- **Détecter** rapidement les fautes (aléatoires / systématiques) sur CPU, mémoire, horloges, communication.
- **Réagir** de manière déterministe (safe state, reset contrôlé, dégradation) avec une latence maîtrisée.
- **Tracer** les défauts (événements, DTC, compteurs, reset reason) pour analyse.

### Mécanismes safety typiques côté MCU/plateforme
- **Watchdog** : HW WDG (fenêtré si possible) + supervision du servicing.
- **Supervision d’horloges** : clock monitor / PLL lock detect / fréquence.
- **Mémoire** : ECC (SRAM/Flash), parity, contrôles d’intégrité (CRC) sur zones critiques.
- **CPU** : lockstep / comparateur / monitors (si disponibles) + traps.
- **Self-tests** : (LBIST/MBIST/BIST, CPU self-test) au démarrage et/ou périodiques.
- **MPU / protection mémoire** : isolation de zones (stack, données safety, registres).
- **Supervision d’alimentation** : brown-out, under/over-voltage, reset supervision (souvent via PMIC).
- **Reset reason** : lecture et journalisation de la cause (Wdg, brown-out, SW reset, etc.).

### Mécanismes safety typiques côté BSW
- **DET** (bring-up) : détecter rapidement les erreurs d’API / config.
- **DEM/DCM** : remonter les événements safety en DTC / UDS (si diag activé).
- **SchM + exclusive areas** : protéger les zones critiques (éviter race conditions).
- **OS (AUTOSAR OS)** :
  - **Timing protection** (surconsommation CPU, deadlines)
  - **Stack monitoring** (overflow)
  - **Memory protection** (si dispo)
  - stratégie claire ISR Cat1/Cat2 + priorités
- **E2E protection** (si COM/signaux) : CRC, compteur, alive counter, timeout, plausibilité.
- **NvM/Memory stack** :
  - intégrité des blocs (CRC)
  - gestion des erreurs (fallback defaults / safe values)
  - stratégie de recovery après reset

### Recommandations d’intégration (pragmatiques)
1. **Bring-up safety minimal** : activer WDG (ou au moins le préparer), log reset reason, activer DET, mettre en place une “safe loop” de secours.
2. **Définir le safe state** : sorties (Dio/Pwm), CAN (NoCom), diag, NVM — que fait l’ECU en cas de faute ?
3. **Supervision périodique** :
   - tâche 10ms/100ms de health monitoring (compteurs, temps d’exécution, checks)
   - surveillance “alive” des tâches principales
4. **Communication** : si ASIL D implique une comm safety, ajouter E2E + timeouts + plausibility et une stratégie de dégradation.
5. **Mémoire / NVM** : décider quelles données sont safety-relevant, activer CRC, et prévoir un chemin “safe defaults” si corruption.
6. **Diagnostics** : mapper les fautes safety (watchdog, clock, ECC, timeout) en événements DEM + services DCM (si applicable).
7. **Séparation** : isoler autant que possible les fonctions safety vs non-safety (tâches, priorités, ressources, zones mémoire).

### Checklist ASIL D (exemples concrets)
- Watchdog fenêtré configuré + stratégie de servicing (qui le sert, quand, conditions).
- Reset reason lu au boot + journalisation + incrément de compteur (option) en NVM.
- Tick OS stable + détection de dérive (si mécanisme dispo) + timing protection.
- CRC / signatures sur tables de config critiques (si applicables).
- Timeouts Rx/Tx CAN et réaction (NoCom / safe state).

### Questions à clarifier (pour “coller” au SR6P7)
- Quels blocs safety SR6P7 sont disponibles/activables (lockstep, monitors, BIST, MPU, ECC par mémoire) ?
- Quelle stratégie de safe state côté HW (PMIC, reset) vs SW (degraded mode) ?
- Comment le package MCAL/OS expose ces mécanismes (APIs, callbacks, config) ?