Bureau d’étude Electronique Automobile - Alexandre …alexandre-boyer.fr/alex/enseignement/enonce...
Transcript of Bureau d’étude Electronique Automobile - Alexandre …alexandre-boyer.fr/alex/enseignement/enonce...
BE électronique automobile 5e année ESE
Bureau d’étude Electronique Automobile
http://www.alexandre-boyer.fr
Alexandre Boyer
Patrick Tounsi
5e année ESE
Octobre 2017
BE électronique automobile 5e année ESE
2
Contenu
I - Contexte ............................................................................................................................. 3
II - Objectifs du bureau d’étude ............................................................................................ 5
III - Enoncé du BE – Cahier des charges ................................................................................ 6
1. Présentation générale du projet ....................................................................................... 6
2. Cahier des charges ........................................................................................................... 7
a. Exigences fonctionnelles ............................................................................................. 7
b. Exigences sur le BCM ............................................................................................. 9
c. Exigences sur le DCM ................................................................................................. 9
d. Exigences sur le cluster d'instrumentation ............................................................... 9
e. Exigences sur la communication CAN ........................................................................ 9
f. Exigences Basse consommation ................................................................................ 11
g. Exigences sur la surveillance de l’alimentation ..................................................... 11
h. Exigences en terme de diagnostic des charges....................................................... 12
i. Exigences CEM ......................................................................................................... 12
IV - Organisation et Planning ............................................................................................... 13
V - Notation ......................................................................................................................... 13
VI - Liste des documents disponibles en ligne ..................................................................... 14
VII - Annexe 1 – Format des documents à rendre .............................................................. 14
1. Spécification matérielle ................................................................................................. 14
2. Spécification logicielle .................................................................................................. 15
3. Rapport final ou d’avancement ..................................................................................... 17
VIII - Annexe 2 – Présentation du matériel ......................................................................... 19
1. Les maquettes ................................................................................................................ 19
a. Module portière ......................................................................................................... 19
b. Maquette tableau de bord ....................................................................................... 19
2. Cluster d'instruments ..................................................................................................... 22
3. Les cartes électroniques ................................................................................................ 24
a. MC33887 – Pont en H ............................................................................................... 24
b. MC33984 – Dual High side switch ........................................................................ 25
c. Kit de développement TRKMPC5606B - Sonde USB Multilink Universal ............. 26
d. Carte d’interface ..................................................................................................... 27
IX - Annexe 3 - Prise en main du matériel ........................................................................... 30
1. Prise en main de la carte MC33887 .............................................................................. 30
2. Prise en main de la carte MC33984 .............................................................................. 30
3. Prise en main de l’outil de programmation NXP CodeWarrior Development Studio for
Micro v10.7 .......................................................................................................................... 30
4. Exemples de codes sources - Librairie .......................................................................... 35
BE électronique automobile 5e année ESE
3
I - Contexte Dans les véhicules actuels sont embarqués de nombreux composants électroniques
(microcontrôleur, capteur, actionneur de puissance, …) permettant d’améliorer la fiabilité du
système, la sécurité et le confort des passagers et le rendement énergétique. La mise en place
et l’optimisation de tous ces organes électroniques à l’intérieur d’un véhicule nécessite un
savoir faire large en électronique (analogique, numérique, puissance) et en informatique
matérielle. La figure ci-dessous décrit l’architecture typique d’une application automobile.
Microcontrôleur
Contrôleur central
Microcontrôleur
Pilotage des actionneurs
Charge (Moteur, lampe, …)
Actionneurs –circuit puissance
Ex : bus CAN
Bus de communication
Microcontrôleur
… Contrôle/Acquisition
réseau
Alimentation de
la charge
CapteurAcquisition
Commande manuelleAcquisition
Une charge (ampoule, LED, moteur) est pilotée par un actionneur capable de délivrer le
courant nominal absorbé par la charge. Ce circuit de puissance est lui-même commandé par
un microcontrôleur. Les circuits de puissance utilisés dans l’industrie automobile ne sont pas
de simples commutateurs de puissances puisqu’ils intègrent aussi toute une partie logique de
contrôle, disposent de plusieurs modes de fonctionnement et renvoient de nombreuses
informations comme la température ou le courant débité. L’actionnement des charges dépend
des informations acquises et envoyées par un ensemble de capteurs aux organes de contrôle.
Tous ces organes de contrôle forment un réseau interconnecté par un ou plusieurs bus, comme
le bus standard CAN.
En raison des exigences économiques, de sûreté de fonctionnement et de robustesse, le
processus de conception d’une application automobile suit souvent un cycle particulier,
appelé cycle en V, décrit à la figure ci-dessous.
Ce cycle de conception a pour objectifs de faciliter l’élaboration d’un produit final à partir de
spécifications client, vérifier la cohérence et le respect des spécifications client à chaque étape
et le « debug » des problèmes. Dans le cadre du développement d’une application
électronique automobile, les différentes étapes sont :
1. Exigences équipementiers : A partir des exigences ou spécifications client,
l’équipementier définit son propre cahier des charges. Le cahier des charges contient
des exigences fonctionnelles et des contraintes auxquelles doit répondre l’application.
2. Exigences systèmes par discipline : les exigences en différentes disciplines : logicielle
(code embarqué), électronique (conception carte et choix composants) et mécanique. Il
est nécessaire de s’assurer que les exigences systèmes doivent se conformer aux
exigences de la phase 1. Dans le cadre de ce BE, nous mettrons l’accent sur les
BE électronique automobile 5e année ESE
4
solutions matérielles et logicielles pour garantir la robustesse et la qualité énergétique
du système.
Customer
requirements
9. Vehicle test
Time
Detail
Level
1. Supplier
requirements
4. Design
report
5. Coding
7. ITS/VTS
8. System tests
Satisfy ?
Satisfy ?
Satisfy ?
Verify ?
Verify ?
Verify ?
Verify ?
Final delivery
6. Module tests
2. System requirements
per disciplines
3. Software architecture
requirements (modules)
3. Exigences d’architecture logicielle : l’analyse des exigences logicielles permet de
proposer l’architecture de l’application logicielle, décomposée en modules. Les
exigences logicielles sont décrites dans un rapport. Il est nécessaire de s’assurer que
les exigences systèmes se conforment aux exigences de la phase précédente.
4. Exigence design : Chaque module est décomposé en fonctions. Il est nécessaire de
s’assurer que les exigences systèmes se conforment aux exigences de la phase 3. Les
tests modulaires peuvent être définis à cette étape (pas leur mise en œuvre).
5. Codage : Il s’agit de l’écriture proprement dite du code permettant de satisfaire aux
exigences de design. Le codage est soumis à un ensemble de recommandations et de
contraintes afin d’en améliorer la portabilité, la lisibilité, la robustesse …
6. Tests modulaires : Chaque fonction doit être testée et validée. Des vecteurs de tests
sont choisis afin d’obtenir une couverture de test = 100 % et garantir le bon
fonctionnement de l’application finale. Un rapport est créé qui détaille le test des
fonctions. On s’assure que toutes les exigences définies en 4 sont respectées.
7. Integration Test Specification (ITS) / Verification Test Specification (VTS) : Le test
ITS permet de s’assurer la bonne compatibilité entre les modules, leur initialisation
correcte, leur bonne communication, la bonne récurrence des fonctions dans le
temps. Le test VTS permet de s’assurer que les exigences sont respectées. On s’assure
qu’on respecte toutes les exigences définies en 3.
8. Tests système : On vérifie sur l’équipement l’ensemble du code. On s’assure qu’on
respecte toutes les exigences définies en 2.
BE électronique automobile 5e année ESE
5
9. Tests véhicule : il s’agit du test final avant le livrable pour le client.
L’organisation de ce bureau d’étude suivra ce type de cycle de conception, dans la mesure du
temps et du matériel disponible. Le travail réalisé durant les 9 séances de BE s’inscrit dans les
étapes 3, 4, 5, 6 et 7 de ce cycle de conception.
II - Objectifs du bureau d’étude Le but de ce bureau d’étude est de réaliser une application automobile basé sur l’architecture
précédente en suivant un processus de développement industriel. L’application à réaliser est
spécifiée par un cahier des charges définissant non seulement les exigences fonctionnelles,
mais aussi les exigences en termes de gestion d’énergie, de sûreté (safety), de robustesse du
système aux erreurs et aux pannes, de compatibilité électromagnétique (EMC).
Pour cela, vous disposez d’un ensemble de composants électroniques dédiés aux applications
automobiles, fournis par la société NXP Semiconductor, et des logiciels de programmation
associés (CodeWarrior).
Les objectifs du bureau d’étude sont les suivants :
� mettre en place une architecture typique d’une application automobile
(microcontrôleur, actionneur, charge, bus)
� développer un projet complet : mise en place du cahier des charges, développement
logiciel et mise en œuvre pratique à l’aide de composants électroniques
� proposer des solutions logicielles et matérielles améliorant la sûreté de fonctionnenet
(safety), le confort du conducteur et des passagers, réduisant la consommation
d’énergie, le risque d’erreurs matérielles et logicielles et permettant le diagnostic du
système
� se familiariser aux composants industriels automobiles (microcontrôleur, transceiver
CAN, high side switch, superviseur d’alimentation, System Basis Chip) et aux
contraintes de ce domaine
� mettre en réseau l’ensemble des composants en utilisant un bus de terrain tel que le
bus CAN (Controller Area Network)
� Fonctionnement d'un cluster d'instruments (jauge, écran LCD)
BE électronique automobile 5e année ESE
6
III - Enoncé du BE – Cahier des charges
1. Présentation générale du projet Votre équipe est en charge du développement du système de gestion des portières du véhicule
et du cluster d'instruments. Cette application est répartie entre plusieurs ECU (Electronic
Control Unit) :
� Le contrôleur habitacle ou Body Controller Module (BCM), qui gère l’interface avec
l’utilisateur et reçoit les informations de diagnostic d’autres ECU tels que le Door
Control Module.
� Le contrôleur Door Control Module (DCM), qui gère l’allumage des phares et
clignotants, ainsi que la détection de pannes éventuelles.
� Le cluster d'instruments, qui gère l'affichage des informations véhicule au conducteur
Ces différents modules communiquent sur un réseau CAN (Controller Area Network) –
ISO11898. La figure ci-dessous décrit l’architecture matérielle de l’application et
l’interconnexion entre les différents équipements.
Battery
VBAT (12 V)
Microcontroller
CAN interface
Superviseur alim -
Watchdog
SBCVDD (5 V)
5V_CANRST
INT
User button LED indicator
Vsup
Microcontroller
CAN interface
Superviseur alim -
Watchdog
SBCVDD (5 V)
5V_CANRST
INT
LED indicator
Vsup
Power switch 1
Door Locking
Power switch 2
Window winder
…
Body Control Module (BCM) Door Control Module (DCM)
Commande
Diagnostic
Lecture courant charge
Instrument cluster
TFT-LCD panel
CAN bus
Gauges
Votre travail consiste à développer l’application gestion fonctionnelle et de diagnostic en
temps réel, embarquée dans le BCM, le DCM et le cluster d'instruments. Cette application
doit respecter les exigences définies dans le cahier des charges ci-dessous.
Vous pourrez vous appuyer sur les travaux de l'an dernier, portant sur l'interconnexion entre le
BCM et le DCM (Door Control Module), qui étaient développés sur les mêmes cibles
matériels. La mission consistera à finaliser l’application et ses tests. L'ensemble des travaux
effectués l'an dernier (rapport de conception, codes sources, avancement du projet) sont
disponibles sur le site http://www.alexandre-boyer.fr/enseignements.
Votre travail se décompose en différentes parties :
BE électronique automobile 5e année ESE
7
1. Ecrire la spécification de l’architecture matérielle et logicielle de l’application (voir
annexe 1 pour le contenu)
2. Répartition des tâches après désignation du chef de projet
3. Reprendre et poursuivre le travail de développement
4. Définir des vecteurs de tests, tester et valider chaque module (voir annexe 1 pour le
contenu du rapport d’avancement et de test)
5. Tester et valider l’application complète
6. Délivrable final : Rapport détaillé et codes sources
Vous développerez et testerez vos modules logiciels sur des kits de développement NXP et le
cluster d'instrumentation (voir annexes 2 et 3). Les tests pourront être effectués sur des kits de
développement différents.
Remarque : Même s’il s’agit d’un travail individuel, le travail sur la spécification de
l’application et le test final est un travail de groupe. Une proposition de découpage du travail
entre les élèves de façon équilibrée est indispensable.
2. Cahier des charges
a. Exigences fonctionnelles
Description de la fonction lève vitre
La commande lève vitre est assurée par :
� deux boutons poussoirs situés sur la portière (on simulera ces 2 boutons poussoirs par
ceux disponibles sur la carte de développement TRK-MPC5606B), actionnés par un
conducteur ou un passager. Le premier commande la montée du lève vitre, le second
la descente. En cas d’appui simultané, la fonction est inhibée. Dans le cas d’un appui
long (> 100 ms), la montée/descente de la vitre se fera en mode manuel (l’action dure
tant que l’utilisateur appuie sur le bouton). Dans le cas d’un appui court (< 100 ms), la
montée/descente de la vitre se fera en mode automatique (l’action dure tant que
l’utilisateur n’appuie pas à nouveau sur un des boutons poussoirs).
� Si le véhicule n’est pas mis en marche et si de la pluie est détectée, les vitres doivent
remonter automatiquement. L’information pluie est transmise au BCM qui envoie
ensuite un ordre de fermeture de la vitre au DCM, à condition qu’aucune panne n’ait
été détectée dans la portière. Vous pourrez simuler les différentes informations
parvenant au BCM par les boutons poussoirs ou interrupteurs disponibles sur la carte
de développement TRK-MPC5606B.
La commande du lève-vitre est assurée par le H-bridge MC33887. Le pilotage du moteur du
lève vitre se fait par une commande PWM. Elle ne doit produire aucun bruit parasite pour le
passager.
La montée ou la descente complète de la vitre doit être réalisée en 4 secondes. Quel que soit le
mode de montée/descente de la vitre, l’action s’arrête dès que la vitre arrive en butée. La
détection de la butée se fait par la mesure du courant délivré par le moteur.
Le DCM intègre une fonction critique du point de vue de la sécurité des passagers : le système
anti-pincement (voir partie j – Exigences safety). Le DCM doit être capable de détecter le
pincement d'un objet et de le distinguer d'une détection de butée.
BE électronique automobile 5e année ESE
8
Scénario dans le cas où l’ordre de lève vitre provient du BCM :
Le BCM transmet l’ordre de montée de la vitre de la portière et demande au DCM d’acquitter
l’opération. A la fin de l’opération lève-vitre, le DCM transmet un acquittement au BCM.
Si le DCM ne répond pas au bout de 5 s, le BCM renvoie à nouveau l’ordre de montée de la
vitre. En cas d’absence de réponse, il renouvelle 4 fois la demande. Au bout de 5 demandes
sans réponses, le BCM abandonne la demande d’acquittement.
Vous pourrez limiter votre travail à un seul bloc portière.
Description de la fonction verrouillage portière
La commande de verrouillage de la portière est assurée par :
� Un bouton poussoir situé sur la portière (on le simulera à l'aide d'un bouton poussoir
disponible sur la carte de développement TRK-MPC5606B), actionné par le
conducteur ou un passager. L’action est détectée par le DCM.
� Un bouton poussoir situé sur le tableau de bord (on le simulera à l'aide d'un bouton
poussoir disponible sur la carte de développement TRK-MPC5606B), actionné par le
conducteur ou un passager. L’action est détectée par le BCM.
� Si la vitesse du véhicule passe au-dessus de 10 km/h, la portière est automatiquement
verrouillée afin d'empêcher un vol du véhicule (anti-hijacking system).
La commande du verrouillage de la portière est assurée par le H-bridge MC33887.
On supposera que l'information vitesse est fournie par le BCM. Celle-ci pourra être simulée.
Description de la fonction cluster d'instruments
Le cluster d'instruments devra afficher :
� la vitesse sur l'indicateur de vitesse. On supposera que l'information vitesse est fournie
par le BCM. Celle-ci pourra être simulée.
� Une image de bienvenue s'affichera sur l'écran LCD au démarrage du véhicule
pendant l'initialisation de l'ensemble des calculateurs du véhicule. Cette image restera
afficher pendant 5 secondes.
� Une image du véhicule vue de dessus (bird's eye view), indiquant sur l'écran LCD le
statut de verrouillage des portières et d'ouverture des fenêtres sera affichée.
� Une icône indiquant l'activation du système anti-hijacking s'affichera lorsqu'il sera
activé.
� Une icône indiquant la fermeture automatique de la vitre s'affichera en cas de
détection de pluie. Celle-ci restera afficher pendant 5 secondes.
� En cas de problème d'une des commandes de la portière, le témoin d'incident sera
allumé. De plus, sur l'écran LCD, une icône se superposera à l'image du véhicule pour
indiquer où se situe le problème et quel organe il touche (verrouillage portière ou lève
vitre). Dès que le problème sera résolu, cette icône disparaitra et le témoin d'incident
s'éteindra.
� En cas de détection de pincement par le lève-vitre, une alerte sera affichée sur l'écran
LCD.
� En cas de tension de batterie faible, le témoin suivant est allumé .
BE électronique automobile 5e année ESE
9
b. Exigences sur le BCM
Deux modes de fonctionnement sont proposés pour le BCM :
• Mode de fonctionnement nominal :
La fréquence d’horloge du bus système du BCM est fixée à 64 MHz. Elle est fournie par le
module FM-PLL à partir d’un oscillateur à quartz externe de 8 MHz. La tolérance sur la
fréquence du quartz est inférieure à 0.5 %. La modulation de fréquence sera activée (cf.
Exigences CEM).
• Mode basse consommation :
Cf. Exigences basse consommation.
c. Exigences sur le DCM
Deux modes de fonctionnement sont proposés pour le DCM :
• Mode de fonctionnement nominal :
La fréquence d’horloge du bus système du DCM est fixée à 32 MHz. Elle est fournie par le
module FM-PLL à partir d’un oscillateur à quartz externe de 8 MHz. La tolérance sur la
fréquence du quartz est inférieure à 0.5 %. La modulation de fréquence sera activée (cf.
Exigences CEM).
• Mode basse consommation :
Cf. Exigences basse consommation.
d. Exigences sur le cluster d'instrumentation
Le cluster d'instrumentation n'aura qu'un mode de fonctionnement : le mode nominal. La
fréquence d'horloge du bus système sera fixé à 100 MHz. Elle est fournie par le module FM-
PLL à partir d'un oscillateur à quartz externe de 8 MHz. La tolérance sur la fréquence du
quartz est inférieure à 0.5 %. La modulation de fréquence sera activée (cf. Exigences CEM).
Au démarrage, une image d'accueil sera affichée pendant 5 secondes. Les données graphiques
seront stockées en mémoire SRAM graphique (espace de 1 MBytes).
e. Exigences sur la communication CAN
Le module DCM et le cluster d'instruments communiquent avec le module BCM par un bus
CAN. La longueur maximale du bus CAN entre le DCM ou le cluster d'instrumentation et le
BCM est de 5 mètres. La liaison CAN est assurée par une paire bifilaire. Le temps de
propagation le long de la paire est de 5 ns/m. Le retard maximal introduit par un contrôleur
CAN ou un transceiver CAN est estimé à 25 ns.
Exigences sur le débit binaire
Le bus CAN fonctionne selon la spécification CAN 2.0B. Le débit binaire doit être supérieur
à 1 Mbits/s en mode de fonctionnement nominal. Il sera ramené à 125 Kbits/s en mode
dégradé. L'horloge du périphérique du CAN sera issue de l'oscillateur à quartz à 8 MHz.
BE électronique automobile 5e année ESE
10
Exigences sur le format des trames CAN
Le Standard CAN 2.0B est utilisé. Seules des trames de données sont transmises. Les remote
frames ne sont pas utilisées. Les données sont transmises par paquet de 8 octets. Le choix des
identifiants doit se conformer au format suivant :
11 bits 18 bits
Identificateur 29 bits
Sujet du message Source du message
MSB LSB
L’adresse (source du message) donnée au BCM sera ‘0x00000’. Celle pour le LCM sera
‘0x10000’. Celle pour le cluster d'instruments sera '0x20000'.
Gestion de la consommation d’énergie
Cf. Exigences basse consommation. Lorsque les microcontrôleurs entreront en mode basse
consommation, les contrôleurs CAN entreront en mode Disable. Les interfaces CAN entreront
en mode Sleep. Ceux-ci sortiront des modes basse consommation soit par demande du
microcontrôleur, soit par requête sur le bus CAN. Un pattern correspondant à 3 impulsions à
l’état dominant sera utilisé pour réveiller les interfaces CAN. Une impulsion sur la ligne INT
indiquera la sortie du mode Sleep de l’interface CAN. Cette exigence ne concernera pas le
cluster d'instruments.
Gestion des erreurs de transmission et de réception sur le bus CAN
Dans le cas d’erreurs de transmission ou de réception, seules les entrées et les sorties de l’état
Bus Off sont repérées. Pour le BCM, la sortie de l’état Bus Off se fait par une requête du
contrôleur, après l’entrée dans l’état Bus Off. Après 5 entrées consécutives dans l’état Bus Off,
une erreur est affichée sur le tableau de bord et la demande en cours est abandonnée.
Pour le DCM, la sortie de l’état Bus Off est automatique (selon la spécification du protocole
CAN 2.0B : 128 occurrences de 29 bits récessifs).
Cette exigence ne concernera pas le cluster d'instruments.
Inactivité sur le bus CAN
Si un contrôleur CAN ne transmet rien pendant plus de 2 secondes, celui-ci devra passer en
mode Listen Only. L’interface CAN passera en mode Receive Only.
Cette exigence ne concernera pas le cluster d'instruments.
Gestion des problèmes matérielles sur le bus CAN
Le System Basis Chip (SBC) intègre une interface CAN capable de détecter des problèmes
électriques sur le bus CAN, sur les broches Rx et Tx et une surtempétaure de l’interface CAN.
En cas de problème matériel, l’interface CAN enverra une impulsion sur la ligne INT. Le
microcontrôleur détectera l’origine du problème et notifiera la présence d’une erreur en
allumant un indicateur lumineux. L’interface CAN sera mise en mode Receive Only, tant que
le problème n’a pas disparu. Le microcontrôleur cherchera régulièrement à faire revenir
l’interface CAN en mode d’émission/réception normal.
En cas de problème relevé sur l’alimentation 5V_CAN, la même procédure sera appliquée
mais l’interface CAN passera en mode Sleep.
BE électronique automobile 5e année ESE
11
Remarque : le SBC pourra être configuré en mode debug pour faciliter la tâche de
développement et de test.
Cette exigence ne concernera pas le cluster d'instruments.
f. Exigences Basse consommation
Lorsque les cœurs des microcontrôleurs n'ont aucune opération à effectuer, ils seront éteints.
Modes de consommation des microcontrôleurs
Deux modes de consommation d’énergie sont définies pour les microcontrôleurs :
� Mode Run0 : fonctionnement normal.
� Mode basse consommation STOP0 : voir détails ci-dessous.
Le BCM passe en mode STOP0 si sa période d’inactivité dépasse 10 secondes. Il sort de ce
mode dans les cas suivants :
� Un message lui est adressé sur le bus CAN
� L’utilisateur appuie sur une commande d'ouverture/fermeture de portière ou du lève-
vitre
� Un problème matériel est détecté par le superviseur d’alimentation ou l’interface CAN
(signal INT)
� La limite de vitesse anti-hijacking est détectée
� La pluie est détectée
Avant d’entrer en mode STOP0, le microcontrôleur s’assure que l’interface CAN est entrée en
mode Sleep et que le contrôleur CAN est entré en mode Disable.
Le DCM passe en mode STOP0 si sa période d’inactivité dépasse 10 secondes et si aucun
phare n’est allumé. Il sort de ce mode dans les cas suivants :
� Un message lui est adressé sur le bus CAN
� Un problème matériel est détecté par le superviseur d’alimentation, l’interface CAN
(signal INT) ou un des drivers de charge
Avant d’entrer en mode STOP0, le microcontrôleur s’assurer que l’interface CAN est entrée
en mode Sleep, que le contrôleur CAN est entré en mode Disable et que les drivers de charge
(inactifs) sont entrés en mode Sleep.
g. Exigences sur la surveillance de l’alimentation
L’alimentation du BCM et du DCM est issue de la batterie Vbat. Le superviseur
d’alimentation (SBC) fournit une alimentation 5 V (Vdd) régulée au microcontrôleur. Le SBC
surveille la qualité de ces différentes alimentations (surtension, sous-tension, présence
d’impulsions parasites, load dump, crank phase). En fonction de la tension mesurée par le
SBC, plusieurs scénarios sont prévus (voir datasheet SBC MC33905 pour plus d’informations
sur les différentes tensions mesurées par le SBC) :
� Si la tension Vsense devient inférieure à 8.6 V ou si la tension Vsup devient inférieure
à 6 V, le SBC envoie une impulsion sur la ligne INT. Le microcontrôleur du BCM
vérifie la valeur de la tension batterie (Vsense) et notifie ou non le risque de tension de
batterie faible en allumant l'indicateur lumineux .
BE électronique automobile 5e année ESE
12
� Si la tension d’alimentation Vdd du microcontrôleur devient inférieure à 4 V, les
microcontrôleurs sont mis en reset.
� Si la tension Vsup est inférieure à 4 V (crank phase), le régulateur du SBC délivrant la
tension Vdd est désactivé.
� Si un problème est relevé sur la tension d’alimentation 5V_CAN de l’interface CAN
(overcurrent, underevoltage, overtemperature), celle-ci passe en mode Sleep jusqu’à
ce que le problème disparaisse.
h. Exigences en terme de diagnostic des charges
Le module DCM vérifie l’état des switches de puissance et fait remonter toute défaillance au
BCM (overtemperature, overcurrent, overvoltage, open load).
Dès qu’un problème est signalé sur un switch, un message ou une image s'affichera sur l'écran
LCD du cluster d'instruments afin d'indiquer la nature du problème pendant 5 secondes. Le
témoin d'incident restera allumer pendant toute la durée du problème. La commande du
switch est coupée jusqu’à ce que le problème disparaisse. Lorsque le problème a disparu, le
DCM transmet au BCM un message indiquant le recouvrement de la panne. Les indications
de panne affichées par le cluster d'instruments disparaissent.
i. Exigences CEM
Afin de réduire les émissions électromagnétiques parasites, la modulation FM de la PLL de
chaque microcontrôleur sera activée. Celle-ci sera réglée afin de minimiser l’émission
électromagnétique.
Toutes les sorties digitales du microcontrôleur, les sorties CAN_H et CAN_L des interfaces
CAN et les sorties de puissance seront configurés en mode « slow slew rate », sauf si des
sorties rapides sont requises.
BE électronique automobile 5e année ESE
13
IV - Organisation et Planning Un groupe de TP travaille ensemble au développement de l’application. Le groupe travaille à
la spécification logicielle de l’application et à sa validation. Un chef de projet est désigné pour
le groupe et les tâches sont réparties sur l’ensemble des élèves. Chaque élève doit mener à
bien des tâches bien définies. Les travaux de spécification, de codage et de test de chaque
module de l’architecture logicielle sont répartis entre les différents élèves. La répartition de ce
travail est libre mais doit rester équilibrée. La notation par élève dépendra du travail effectué.
La date limite pour fournir le rapport de spécification est le vendredi 24 novembre 2017. La
date limite pour le rapport de conception est le : mercredi 24 Janvier 2017. Une soutenance
est prévue le vendredi 26 janvier 2018 durant laquelle l'équipe présentera les travaux réalisés
Pour toute question technique portant sur les composants NXP, envoyez un e-mail
simultanément aux encadrants de TP : [email protected] et
V - Notation La notation portera sur les rapports techniques rédigés par groupe, ainsi que sur l’évaluation
orale. La répartition de la note est la suivante :
� 1/2 pour le rapport de spécification
� 1/2 pour le rapport de conception et la réalisation
Conseils pour les rapports de spécifications, de codage et de tests :
� Présenter le projet de manière synthétique et claire.
� Utiliser des outils graphiques adaptés, facilitant la compréhension de vos algorithmes
et le codage des applications (voir annexe 1).
� Décrire l’architecture matérielle en faisant apparaître les branchements entre les
différentes cartes, les entrées-sorties utilisées, les types de signaux, les fréquences, les
niveaux de tension, les débits binaires, les options d’entrée-sortie (pull-up, pull-
down …). Toute entrée-sortie dont le statut n’est pas détaillé rend la spécification
matérielle imprécise (voir annexe 1).
� Décrire les solutions apportées pour respecter les contraintes fonctionnelles, de
sécurité, de dimensionnement du bus CAN et de gestion de l’énergie.
� Les codes sources doivent être suffisamment et correctement documentés. le code
source, des commentaires doivent être associés à chaque fonction et indiquer : le rôle
de la fonction, les variables d’entrées et de sorties.
� A l’issue du projet, un rapport d’avancement et de test vous est demandé. Celui-ci doit
montrer quelles exigences ont pu être pris en compte durant votre travail et si elles ont
été respectées (voir annexe 1).
BE électronique automobile 5e année ESE
14
VI - Liste des documents disponibles en ligne Sur la page web http://www.alexandre-boyer.fr/enseignements.htm, un ensemble de
documents sont disponibles :
� enonce BE automobile 5SE_2017-2018_v1.pdf : l'énoncé du bureau d'étude
� Presentation_of_MPC5606B_2017-18.pdf : un document d'aide à la programmation
du microcontrôleur MPC5606B
� Presentation_of_MPC5645S_2016-17.pdf : un document d'aide à la programmation du
microcontrôleur MPC5645S
� Des liens vers les datasheets des composants NXP utilisés (MPC5606B, MPC5645S,
superviseur d'alimentation, switches de puissance) et des starter-kits
� Des liens vers les datasheets des capteurs montés sur le tableau de bord (capteur de
luminosité, capteur de température)
� rapports_etudiants_2015-16.zip : rapport de conception et codes sources du projet de
l'an dernier. Inclut aussi le rapport de spécification de l'année 2014-15.
� exemples_codes_sources_MPC5606B.zip : quelques exemples de codes sources
simples pour prendre en main le MPC5606B (voir IX.4)
� Cook book ISO26262
VII - Annexe 1 – Format des documents à rendre
Un des objectifs derrière les différents rapports qui vous sont demandés est l’écriture de
rapports techniques professionnels. Ces rapports ont un but précis : spécification matérielle,
logicielle et test. Quelques conseils pour l’écriture des rapports :
� Le rapport doit être synthétique et précis. Ce n’est pas la quantité de pages qui compte,
mais la rigueur du document.
� N’hésitez pas à synthétiser les informations par des tableaux et des schémas clairs et
adaptés.
� Utilisez un format unique et lisible pour vos rapports.
Vous pourrez vous appuyer sur les rapports écrits l'an dernier par vos prédécesseurs
(rapports_codes_sources_2015-2016.zip).
1. Spécification matérielle Fournir un schéma de câblage électrique des différents ECU, faisant apparaître l’ensemble des
modules fonctionnels et broches utilisés sur les différents microcontrôleurs et switches de
puissance.
Lister dans un tableau les caractéristiques des entrées-sorties utilisées sur les microcontrôleurs,
avec leurs caractéristiques :
� Type : entrée ou sortie digitale, PWM, entrée analogique, CAN TX ou RX, entrée
quartz …
� Option : pull-up, pull-down, open drain…
� Détaillez la source des signaux d’horloge système et leur fréquence
BE électronique automobile 5e année ESE
15
� Donnez pour les entrées-analogiques la résolution de la conversion, la fréquence de
conversion
� Pour les bus, donnez le débit binaire
� Pour les sorties PWM, donnez les caractéristiques du signal
� Tensions d’alimentation des différents composants
� …
2. Spécification logicielle L’application que vous allez coder provient du cahier des charges du client. Avant de coder
une application, il convient de traduire les spécifications du client en un algorithme et de
s’assurer que cet algorithme répond aux spécifications du client.
La spécification logicielle de l’application que vous allez coder doit se faire à 2 niveaux :
� la spécification de l’architecture logicielle, qui fait apparaître les différents modules
composant l’application et leurs interactions. Il est conseillé de décomposer
l'architecture logicielle en différentes couches : couche pilote, couche service, couche
applicative.
� la spécification de chaque module, qui détaille les fonctions de chaque module
Cette spécification vous permettra de définir votre algorithme. Pour réaliser cette spécification,
différents formats peuvent être utilisés : texte, schéma-bloc, diagramme d’état, flowchart,
UML …
Pour bien comprendre ces deux niveaux de spécifications et les différentes descriptions
pouvant être employées, nous pouvons illustrer par l’exemple de spécification suivant :
« Un client souhaite réaliser une application d’allumage d’une lampe par l’appui sur un
bouton et en fonction de la luminosité ambiante. La figure ci-dessous illustre l’architecture
matérielle de l’application. La lampe est commandé par un driver de puissance, la commande
est de type PWM, la fréquence de la PWM est de 100 Hz, le rapport cyclique de 50 %. La
lampe s’allume lorsqu’on appuie sur le bouton poussoir ou si la tension analogique aux
bornes du capteur lumineux est inférieure à Vref. »
Bouton
poussoir BPCapteur lumineux
Microcontrôleur
Driver de lampe Lampe
Entrée digitale
Entrée analogique
Sortie digitale
A partir de la spécification client, il est possible de décomposer l’application en plusieurs
modules fonctionnels, que l’on peut décrire sous forme de texte (la fonction du module, les
entrées-sorties, les contraintes …) :
� Module « Détection_Appui_BP » : ce module détecte l’appui sur le bouton poussoir et
transmet l’état du bouton poussoir.
BE électronique automobile 5e année ESE
16
� Module « Détection_obscurité » : ce module détecte si la luminosité ambiante passe
sous le seuil (Vcapteur < Vref) et transmet l’état de lumineux ambiant.
� Module « Commande_lampe » : ce module décide de l’allumage de la lampe, en
autorisant la commande PWM.
� Module « PWM_lampe » : ce module génère la commande PWM de la lampe à partir
des paramètres de fréquence et de rapport cyclique, si le module Commande_lampe a
donné son autorisation.
Chacun de ces modules peut aussi être décrit de manière un peu plus précise. La description
d’une application ou d’un module sous forme de texte est certes générale, mais elle reste
surtout adaptée à une description fonctionnelle. Elle n’est pas la plus adaptée à la description
de l’architecture en module ou de la séquence des actions. D’autres outils sont plus adaptés :
Schéma-bloc ou schéma fonctionnel :
Il s’agit d’une représentation graphique d’un processus complexe présentant plusieurs unités.
Le schéma fait apparaître les différents blocs du système, leurs entrées-sorties et les lignes
d’action. La figure ci-dessous propose un schéma-bloc de l’application précédente et fait
apparaître les 4 modules et leurs interactions. Ces différents modules pourront être traduits par
une ou plusieurs fonctions.
Bouton poussoir
Capteur lumineux
Détection_Appui_BP
Détection_obscurité
Commande_lampe
PWM_lampe
Lampe
Digital_In Vcapteur
Etat_BP Etat_lum
En_PWM
PWM_command
Diagramme d’état :
Le diagramme d’état permet de représenter les différents états pris par une machine à états
finis et les conditions à remplir pour passer d’un état à un autre (transition). Un diagramme
d’état présente l’avantage d’être directement traduisible sous la forme d’un algorithme. Par
exemple, voici le diagramme d’état du module Détection_Appui_BP :
Départ
État_BP = 0 État_BP = 1
Front montant
sur Digital_In
Front descendant sur Digital_In
Intialisation
FinApplication
éteinte
BE électronique automobile 5e année ESE
17
Flowchart ou algorigramme :
Le flowchart permet de représenter graphiquement l’enchainement des opérations. Comme le
diagramme d’état, il est traduisible sous la forme d’un algorithme. La figure ci-dessous
présente le flowchart de l’application :
Start
Etat_BP = 0
Etat_lum=0
En_PWM = 0
Initialisation
Etat_BP = 1 ?
Etat_lum = 1 ?
En_PWM = 1
Etat_BP = 1 ?
Etat_lum = 1 ?
En_PWM = 0
yes
yes
no
no
yes
yes
no
no
Dans le cadre de ce BE, il n’y a pas d’obligation à utiliser ces différentes formes de
description pour spécifier l’architecture logicielle que vous allez spécifier. Néanmoins, elles
vous permettront de faciliter la création de vos algorithmes, la validation de vos spécifications
par rapport à la spécification du client, le debug, la collaboration entre les différents groupes
de travail.
3. Rapport final ou d’avancement Le but de ce rapport final est de permettre l’évaluation de l’avancement du projet (qu’est-ce
qui a été fait ? qu’est-ce qui a été validé ? qu’est-ce qui est en cours ? quelles sont les preuves
de la validation ?) et l’adéquation avec le cahier des charges initial. Celui-ci est écrit par
chaque membre de l'équipe et coordonné par le chef de projet. C'est ce dernier qui le rend.
Le rapport d’avancement peut inclure un tableau (Excel par exemple) listant l’ensemble des
spécifications et des modules fonctionnels. A chaque ligne on trouvera :
� une description succincte d’une spécification ou d’un module fonctionnel (exemple :
Configuration horloge système : activation d’une PLL à 64 MHz)
� un statut donnant l’avancement de la tâche de développement d’un module fonctionnel
ou de vérification d’une spécification : Fait, non fait, en cours, abandonné…
BE électronique automobile 5e année ESE
18
� état de la validation : test conforme, test non conforme, test non effectué. Le résultat
de tout test devra être présenté dans un document annexe. Indiquez comment retrouver
le résultat de test (page d’un document, n° de figure, nom de fichiers…).
La validation de tout module fonctionnel ou toute spécification fera appel à un ou plusieurs
tests matériels (mesure à l’oscilloscope, multimètre …) ou logiciels (changement d’état
binaire dans un registre, mesure de temps de cycle …). Ceux-ci devront être détaillés dans un
rapport annexe au rapport d’avancement. Le résultat des tests devra être présenté et commenté
de manière succincte (le résultat attendu, le résultat obtenu). Le format de ce document est
libre. Celui-ci doit rester synthétique.
BE électronique automobile 5e année ESE
19
VIII - Annexe 2 – Présentation du matériel Dans ce BE, nous disposons de plusieurs maquettes, de composants dédiés automobile fournis
par la société NXP Semiconductor, et de cartes d’interface. Les notes d’application des
différents composants vous sont fournies.
L’ensemble des documents sont disponibles sur le site http://www.alexandre-boyer.fr.
1. Les maquettes Six maquettes dédiées à une application automobile sont proposées. Elles sont présentées ci-
dessous accompagnées de leurs fiches signalétiques.
a. Module portière
b. Maquette tableau de bord
La maquette tableau de bord intègre un cluster d'instrumentation (voir partie VIII.2), des
commodos et différents boutons de commande. Il intègre plusieurs interfaces accessibles sur
son coté gauche :
� une alimentation secteur permettant d'alimenter le cluster d'instrumentation
� une fiche USB connectée à une sonde de programmation P&E USB MultiLink
Universal permettant de programmer le microcontrôleur embarqué dans le cluster
d'instrumentation
� quatre fiches Sub D9, donnant accès à l'état des commodos et boutons de contrôle du
tableau de bord.
� une fiche Sub D9 donnant accès aux deux bus CAN du cluster d'instrumentation
BE électronique automobile 5e année ESE
20
Le brochage des fiches Sub-D9 est précisé ci-dessous. Une carte de répartition entre ces fiches
sub-D9 et la carte de connexion vers le starter kit MPC5604B est disponible.
Fiches Sub-D9 Carte de répartition
Brochage Sub-D9 "Commodos" :
Pin Fonction Etat
1 Clignotant * [<= ] == 0 Ohms
* rien == infini
* [=>] == 1 kOhms 2 Feux de route * tirer vers le volant == 0 Ohm
* repos == infini 3 Feux de croisement * [O] == 220 Ohms
* [actif] == 0 Ohm 4 Essuie-glace arrière * repos == 0 Ohm
* [actif] == 1 kOhms
5 Lave-glace * [avant] tirer vers volant == 1 kOhms
* repos == infini
* [arrière] pousser == 0 Ohms
6 Essuie-glace avant * [O] == 2 kOhms
* [vitesse 1] == 0,5 kOhms
* [vitesse 2] == 0,25 kOhms
BE électronique automobile 5e année ESE
21
* [vitesse 3] == 100 Ohms
* [vitesse 4] == 0 Ohm 7 "TRIP" Ouvert/Fermé 8 -NC- 9 gnd
Brochage Sub-D9 "Bloc commande central" :
Pin Fonction Etat 1 [Warning] Ouvert/Fermé 2 LEDs nuit IN 0/12V 3 [Verrouillage-portes] Ouvert/Fermé 4 LED Verrouillage-portes IN 0/12V 5 Capteur température Voir document Grove Light sensor v1.0.pdf
6 Capteur luminosité Voir document Grove Temperature.pdf
7 -NC-
8 -NC-
9 gnd
Brochage Sub-D9 "Volant" :
Pin Fonction Etat 1 & 9 Klaxon Ouvert/Fermé 2 - 8 -NC-
Brochage Sub-D9 "Bloc commande gauche" :
Pin Fonction Etat
1 [Menu ESC] / [+] * [+] == 240 Ohms
* [Menu ESC] == 680 Ohms
* rien == infini 2 [ - ] Ouvert/Fermé 3 Lever / baisser faisceau feu
* Lever == 180 Ohms
* Baisser == 900 Ohms
* rien == Infini 4 feu brouillard arrière Ouvert/Fermé 5 -NC- 6 -NC- 7 -NC- 8 -NC- 9 gnd
Brochage Sub-D9 "Bus CAN" :
Pin Fonction Etat 1 Body CANL 2 Body CANH
BE électronique automobile 5e année ESE
22
3 -NC- 4 Info CANL 5 Info CANH 6 gnd 7 -NC- 8 -NC- 9 -NC-
2. Cluster d'instruments Face avant du cluster d'instruments :
Ecran LCD WQGVA 480x272
Indicateur de vitesse
Compte tourJauge de niveau
de carburant Indicateur de température
Le cluster peut communiquer avec le reste de l'application par l'intermédiaire de deux bus
CAN : le premier est le bus Body CAN (connexion avec le body controller). Il est commandé
par le périphérique FlexCAN1 du microcontrôleur. Le transceiver CAN de ce bus est
physiquement relié au microcontrôleur par les broches CANTX1 et CANRX1 (PB10 et PB11).
Le second bus CAN est le bus Info CAN (celui-ci ne sera pas employé). Il est commandé par
le périphérique FlexCAN0 du microcontrôleur. Le transceiver CAN de ce bus est
physiquement relié au microcontrôleur par les broches CANTX0 et CANRX0 (PB0 et PB1).
Le microcontrôleur du cluster (MPC5645S) se programme par l'intermédiaire d'une sonde
P&E Micro USB Multilink Universal (Port A), directement intégrée dans la maquette tableau
de bord. Il est cadencé par un quartz on-board à 8 MHz. Ci-dessous, la liste des connexions
physiques entre les broches du microcontrôleur et les instruments du cluster.
Commande des afficheurs à aiguilles :
Afficheur Module SMC (Stepper
Motor Control) Broches du
microcontrôleur Indicateur de vitesse Module 0 PD0 à PD3 Compte tour Module 1 PD4 à PD7
BE électronique automobile 5e année ESE
23
Jauge de niveau de carburant Module 2 PD8 à PD11 Indicateur de température Module 3 PD12 à PD15
Les moteurs pas à pas de l'indicateur de vitesse et du compte tour ont les caractéristiques
suivantes :
� rotation de l'aiguille pour un rotation complète du moteur (full step) : 5/3°
� vitesse de rotation maximale : 120°/s
Les moteurs pas à pas des jauges de carburant de température ont les caractéristiques
suivantes :
� rotation de l'aiguille pour un rotation complète du moteur (full step) : 1.5°
� vitesse de rotation maximale : 120°/s
Liste des voyants :
Voyant Description Broches du microcontrôleur
Témoin dysfonctionnement d'airbag PB7 + PC1
Feux de route PK11
Témoin dysfonctionnement de l'ESP PK4 + PC3
Témoin ESP désactivé PK4 + PC2
Témoin d'autodiagnostic PK5 + PC2
Témoin de réserve de carburant PK5 + PC3
Témoin dysfonctionnement ABS PK2+ PC3
Témoin de ceintures non bouclées PK3 + PC2
Témoin de défaillance des freins PK3 + PC3
Clignotant droit PK6 + PC2
Clignotant gauche PK6 + PC3
rouge Témoin d'incident PK10 + PC2
jaune Témoin d'incident PF5 + PC2
Témoin de pression d'huile moteur PK10 + PC3
Témoin feux antibrouillard arrière PF1 + PC2
Témoin préchauffage moteur diesel PF1 + PC3
Témoin insuffisance de charge batterie PF3 + PC2
Témoin de perte de pression pneumatiques PF4 + PC2
Témoin de proximité PF5 + PC3
Témoin de côte PF6 + PC3
Témoin feux antibrouillard avant PM7 + PC2
Témoin feux de position PM7 + PC3
BE électronique automobile 5e année ESE
24
Rétro éclairage du tableau de bord :
Le rétro éclairage du tableau de bord est commandé par la broche PJ3 du microcontrôleur. Le
rétro éclairage des aiguilles du tableau de bord se fait à l'aide de la broche PJ7.
Ecran TFT-LCD :
Le cluster comporte un écran TFT-LCD de référence Sharp LQ042T5DZ11C. Il s'agit d'un
écran WQVGA 480x272. Les images sont codées au format RGB 666 (18 bits par pixel). La
fréquence de rafraichissement de l'image est de 50 Hz. L'écran n'intègre aucun contrôleur
(TCON). Le périphérique DCU du microcontrôleur envoie l'ensemble des commandes
activant l'écran, son rétro éclairage et la synchronisation des données à afficher. Le tableau ci-
dessous liste les connexions physiques entre le microcontrôleur et les commandes de l'écran
TFT-LCD. Les signaux digitaux sont compatibles TTL 3.3 V.
Commande écran LCD Broches du microcontrôleur R0 - R5 (Red) DCU_R2 - DCU_R7 G0 - G5 (Green) DCU_G2 - DCU_G7 B0 - B5 (Blue) DCU_B2 - DCU_B7 NCLK (pixel sampling clock) DCU_PCLK HD (Horizontal synchro) DCU_HSYNC VD (Vertical synchro) DCU_VSYNC DEN (Horizontal data enable) DCU_DE PON (Reset signal) PH5 BL_PWM (Backlight command) PG0 (DCU_B0) VRV (vertical scanning direction)
PG12 (activé si mis à '1')
HRV (horizontal scanning direction) Activation de l'alimentation digitale de l'écran
Activation de l'alimentation Backlight PC1 (activé si mis à '1')
Le pilotage de l'écran est assuré par le module TFT du microcontrôleur MPC5645S. Les
paramètres de configuration temporelle suggérés sont les suivants (se reporter à la
documentation de ce microcontrôleur et du DCU pour la signification de ces termes) :
� pixel clock = 10 MHz
� HSYNC pulse width = 500 ns (polarité négative)
� HSYNC Back-porch pulse width = 4.8 µs
� HSYNC Front-porch pulse width = 4.8 µs
� VSYNC pulse width = 116.2 µs (polarité négative)
� VSYNC Back-porch pulse width = 2.266 ms
� VSYNC Front-porch pulse width = 1.801 ms
3. Les cartes électroniques Plusieurs cartes d’évaluation sont fournies par la société NXP Semiconductor dans le cadre du
BE automobile. L’interfaçage entre les différentes cartes sera assuré par une carte spécifique.
a. MC33887 – Pont en H
Ce composant intègre un pont en H et ses diodes de protection, ainsi que toute la partie
logique d’interfaçage avec un contrôleur externe. Le pilotage se fait à l’aide des signaux de
BE électronique automobile 5e année ESE
25
commande IN1 et IN2. Il peut se faire à l’aide d’une commande PWM, avec une fréquence
maximale de 10 KHz.
Il propose en plus une sortie analogique renseignant sur le courant de sortie afin de mettre en
place une boucle de courant, ainsi qu’une sortie logique Fault Status indiquant des conditions
de fonctionnement anormales (sous tension, sur courant, surchauffe). Comme la plupart des
composants automobiles, il possède plusieurs modes de fonctionnement permettant de réduire
la consommation en énergie : mode normal ou mode sleep. Il est monté sur une carte de
développement KIT33887DWBEVB, décrite sur la figure ci-dessous.
Fiche signalétique :
� Alimentation : 5 – 28 V (on travaillera sous 12 V)
� Courant DC max : 5 A (attention au cas du rotor bloqué)
� Fréquence max PWM : 10 KHz
� Signaux de commandes compatibles TTL/CMOS 5 V
Remarques : la broche FS nécessite une résistance pull-up. Celle-ci n’est pas forcément
présente sur le kit de développement. Une résistance doit être placée sur la sortie FB pour la
conversion courant-tension. La valeur de cette résistance est mal spécifiée. N’hésitez pas à la
vérifier. Ne la changez qu’après vous être assuré que la tension aux bornes de cette résistance
ne dégradera pas toute entrée analogique qui lui serait connectée.
Pour plus de détails, se reporter à la datasheet du composant et de la carte de développement
KIT33887DWBEVB (http://www.alexandre-boyer.fr).
b. MC33984 – Dual High side switch
Ce composant intègre 2 commutateurs de puissance de type high side switchs et leurs diodes
de protection, ainsi que toute la partie logique d’interfaçage avec un contrôleur externe. Ce
composant peut être piloté à l’aide du protocole SPI ou directement en PWM.
Remarque : A noter que la communication via SPI permet d’avoir accès à un plus grand
nombre d’informations sur le statut du composant.
Ce composant peut faire passer un fort courant (jusqu’à 30 A en DC !). Il propose en plus une
sortie analogique (CSNS) renseignant sur le courant de sortie permettant ainsi de mettre en
place une boucle de courant. La présence d’une résistance entre CSNS et la masse est
nécessaire pour assurer une conversion courant – tension.
Le composant propose aussi une sortie logique Fault Status indiquant des conditions de
fonctionnement anormales (sous tension, sur courant, surchauffe). Comme la plupart des
composants automobiles, il possède plusieurs modes de fonctionnement permettant de réduire
BE électronique automobile 5e année ESE
26
la consommation en énergie : mode normal ou mode sleep. Il est monté sur une carte de
développement KIT33981BPNAEVB, présentée sur la figure ci-dessous.
Fiche signalétique :
� Alimentation : 6 – 27 V (on travaillera sous 12 V)
� Courant DC max : 30 A (attention au cas du rotor bloqué)
� Fréquence max PWM : 300 Hz
� Signaux de commandes compatibles TTL/CMOS 5 V
Pour plus de détails, se reporter à la datasheet du composant et de la carte de développement
KIT33984PNAEVB (http://www.alexandre-boyer.fr).
c. Kit de développement TRKMPC5606B - Sonde USB Multilink Universal
Le kit de développement propose le microcontrôleur MPC5606B (Bolero) dans sa version LQ
monté dans un boîtier LQFP 144. Cette carte peut être alimenté soit par port USB, soit par une
alimentation externe DC 9-12 V. L’alimentation on-board peut être régulée par un régulateur
5 V ou par un superviseur d’alimentation de type System Basis Chip (SBC) (MC33905). Ce
composant gère l’alimentation de la carte de développement et intègre une interface CAN. La
sélection de l’alimentation de la carte de développement se fait par le jumper J1.
Un quartz de 8 MHz fournit la référence d’horloge au composant. Sur cette carte, on trouve :
� 4 LEDs connectées aux pins PE4 à PE7
� 4 switchs connectés aux pins PG6 à PG9
� 4 boutons poussoirs connectés aux pins PE0 et PE3
� 1 bouton poussoir de reset
� un potentiomètre connecté à l’entrée de conversion analogique numérique ANP0 (pin
PB4)
� une cellule photovoltaïque connectée à l’entrée de conversion analogique numérique
ANP1 (pin PB5)
� un connecteur Sub-D9 (JP3) connecté à une interface CAN
� Toutes les broches des ports du microcontrôleur (PORTA � PORTH) sont accessibles
à travers les connecteurs P1 à P8.
Vous pouvez vous reporter au document TRK-MPC5606B_SCH.pdf pour avoir la
schématique détaillée de la carte de développement, et au document TRKMPC5606BQSG.pdf
pour plus de détails sur les positions des jumpers.
BE électronique automobile 5e année ESE
27
USB (alimentation et
debug optionnel)
Connexion
Bus CAN
LEDs
Boutons
poussoirs
Switches
Alimentation
9 – 12 V
Potentiomètre
MPC 5606B
Bouton
RESET
PORTA �
PORTH
SBC + Interface
CAN (MC33905)
Connexion
sonde USB
Multilink
La programmation et le debug in-situ du microcontrôleur se fera par l'intermédiaire des
sondes P&E Micro USB Multilink Universal. Celle-ci se connecte sur un port USB du PC et
se branche sur cible alimentée. Deux LED indiquent le statut de l'interface. La LED bleue
indique que l'interface est correctement reconnue par le PC, la LED jaune indique que la cible
est alimentée.
Attention : l'embase de connexion pour la sonde USB Multilink sur le kit TRK_MPC5604B
n'a pas de détrompeur. Des erreurs de connexion sont à craindre ! La photo ci-dessous vous
indique le sens correct de connexion de la sonde.
Fil rouge de
ce côté-ci
Sonde USB Multilink Universal
d. Carte d’interface
La carte TRKMPC5606B représente l’élément central de chaque application. Afin de la
connecter aux différentes cartes de puissance et aux autres cartes microcontrôleur par bus
CAN, une carte d’interface a été développée. Celle-ci est présentée ci-dessous.
Les signaux provenant de la carte TRKMPC5606B proviennent des 8 connecteurs 2*8 ou 2*6,
appelés PORTA � PORTH. Différents types de connecteurs sont utilisés pour se connecter
aux cartes de puissance. En face de chaque broche des différents connecteurs de la carte sont
placés des connecteurs tulipe. Ainsi, les interconnections entre cartes peuvent être réalisées
manuellement en plaçant des fils entre les connecteurs tulipes. L’assignation des broches du
MPC5606B est donc laissée libre.
Les indications sur les connecteurs et le sens de connexion sont reportées sur les cartes.
BE électronique automobile 5e année ESE
28
Remarque 1 : il est de votre responsabilité de veiller à ne pas faire de mauvaise
connexion (exemple : court-circuiter une alimentation à la masse, connecter une sortie
de puissance 12 V sur une entrée digitale).
Remarque 2 : si vous connectez le starter kit TRKMPC5606B à la carte d’interface, vous
devez impérativement relier leurs masses. Hormis sur le connecteur PORTH, aucune pin
des connecteurs PORTA � PORTG n’est connectée au plan de masse du kit TRKMPC5606B.
Plusieurs pins sont disponibles sur le TRKMPC5606B et sur la carte d’interface permettant de
relier les masses ensembles.
Ci-dessous, la vue schématique de la carte d’interface
(Schematic_interface_TRK_MPC5606B.pdf) et la vue top layer
(Top_interface_TRK_MPC5606B.pdf).
BE électronique automobile 5e année ESE
30
IX - Annexe 3 - Prise en main du matériel
1. Prise en main de la carte MC33887 Afin de comprendre le fonctionnement de cette carte, nous allons la faire fonctionner de
manière manuelle. Pour cela, nous allons l’utiliser pour piloter une lampe que nous allons
allumer. Celle-ci peut se piloter à partir d’un signal PWM. Pour ce premier essai, on pilotera la
charge à l’aide d’une tension continue.
� Connecter la lampe sur la sortie du pont en H
� Connecter l’alimentation sans l’allumer (tension 12 V)
� A l’aide de la datasheet de la carte, mettre à ‘0’ ou à ‘1’ les différents signaux logiques
de commande en plaçant ou non des jumpers sur les broches des signaux de contrôle
� Mettre sous tension, plusieurs LEDs sur la carte vous indiquent la mise sous tension du
composant et du sens de fonctionnement du pont en H
2. Prise en main de la carte MC33984 Il est possible de prendre en main cette carte par l’intermédiaire du logiciel SPIGEN.
Cependant, nous préférons utiliser une approche manuelle, sachant qu’il est possible de fixer
l’état des différents signaux logiques directement sur la carte. La charge utilisée est une lampe.
� Connecter la lampe sur une des sorties (SA ou SB)
� Connecter l’alimentation sans l’allumer (tension 12 V)
� A l’aide de la datasheet de la carte, mettre à ‘0’ ou à ‘1’ les différents signaux logiques
de commande. Pour cela, placer correctement les jumpers présents sur la carte
� Mettre sous tension, plusieurs LEDs sur la carte vous indiquent la mise sous tension du
composant et l’état de la sortie
3. Prise en main de l’outil de programmation NXP CodeWarrior Development Studio for Micro v10.7
L’outil NXP CodeWarrior Development Studio for Micro v10.7 (for MCU) permet de
développer, compiler et debugger in-situ des projets pour les différentes familles de
microcontrôleurs développés par NXP sous environnement Eclipse.
Dans cette partie, nous allons brièvement décrire les principales étapes décrire permettant de
lancer l'environnement, de créer un projet pour un microcontrôleur de la famille Qorivva, de
charger l'exécutable sur un microcontrôleur et de faire un debug in-situ.
� Lancer NXP CodeWarrior Development Studio for Micro v10. La fenêtre de dialogue
Workspace Launcher s'ouvre. Vous pouvez sélectionner le chemin d'accès de votre
dossier de travail.
� Au premier démarrage, la fenêtre Welcome s'affiche. Vous pouvez directement cliquer
sur le bouton Go to workbench.
� La fenêtre ci-dessous, appelée Workbench, s'affiche (vide). L'ajustement des multiples
fenêtres est configurable à partir du menu Window dans la barre de menus.
BE électronique automobile 5e année ESE
31
Fenêtre Workbench
Onglet
Projet
Onglet
Commande
Barre de menu
Perspective Switch
(vue C/C++ ou debug)
Editeur de Code
Vue Console, problèmes …
Barre d’outils (selon le
perspective Switch)
Pour construire un projet qui sera embarqué sur le microcontrôleur MPC5606B, suivez-la
démarche présentée ci-dessous :
� Pour construire un nouveau projet, plusieurs méthodes sont possibles. Dans l'onglet de
commande, cliquez sur le bouton New MCU project, ou dans le menu File >
New > Bareboard Project.
� Nommez votre projet, spécifiez le chemin d’accès des fichiers puis cliquez Next.
� Sélectionnez ensuite le composant cible. Pour créer un projet tournant sur le
microcontrôleur MPC5606B, sélectionnez dans la liste : Qorivva > MPC56xxB/C/D
Family > MPC5606B. Cliquez sur Next. Pour un projet sur le microcontrôleur
MPC5645S, sélectionnez : Qorivva > MPC56xxS Family > MPC5645S. Sélectionnez
un projet de type Application.
� Sélectionnez le ou les modes de connexion avec la cible : P&E USB MultiLink
Universal et Open Source JTAG. Cliquez sur Next.
� Indiquez ensuite le langage (langage C), les options d'instruction (VLE) et le format en
virgule flottante (Software par défaut). Terminez en cliquant sur Finish. Le projet
apparaît dans l'onglet Projet, le Perspective Switch est en mode C/C++
. En face du nom
du projet apparaît la zone mémoire où le code exécutable sera stockée (en RAM ou en
Flash). Sélectionnez Flash si vous voulez que celui-ci soit stocké dans une mémoire non
volatile.
� Structure du projet : dossier Prefix, dossier Project Headers, dossiers RAM et Flash,
Project settings, et source. Le projet nouvellement créé est structuré avec, notamment,
les dossiers suivants :
o Project_Headers : contient l'ensemble des fichiers header .h du projet
o Project_Settings : contient l'ensemble des fichiers nécessaires à la compilation
du projet, les fichiers de commande du linker (.lcf), au deug in-situ, au
démarrage du programme embarqué (start-up codes)
o Flash : contient l'ensemble des fichiers programme écrits en mémoire Flash (.elf
contient l'exécutable à charger en mémoire, .map indique les localisations en
mémoire des différentes parties du code)
BE électronique automobile 5e année ESE
32
o RAM : contient l'ensemble des fichiers programme écrits en mémoire RAM (.elf
contient l'exécutable à charger en mémoire, .map indique les localisations en
mémoire des différentes parties du code)
o Source : contient l'ensemble des fichiers sources .c
Quelque soit le microcontrôleur cible, la démarche de conception du code embarqué, de sa
compilation et de son test in-situ est la même :
� Vous pouvez écrire le code source dans les différents fichiers sources et header de votre
projet. Vous pourrez utiliser les exemples de codes sources qui vous sont fournis pour
prendre en main l’outil.
� Une fois le code source écrit, il est nécessaire de le compiler et de construire le projet
exécutable qui sera chargé en mémoire du microcontrôleur. Pour cela, dans l'onglet de
commande, cliquez sur le bouton Build ou dans le menu Project > Build. Il est
cependant nécessaire de définir la mémoire cible au préalable : RAM ou Flash, comme
le montre l'image ci-dessous. Une fois cette étape réalisée, les fichiers exécutables (.elf)
sont écrits soit dans le dossier RAM, soit dans le répertoire projet.
� En cas de problèmes de durant l'opération de "link", il est conseillé d'appuyer sur le
bouton Clean.
� Avant de lancer l'étape de debug in-situ (et donc d'écriture en mémoire), il est
nécessaire de sélectionner le fichier exécutable, correspondant notamment à la mémoire
cible visée : Flash ou RAM. Pour cela, cliquez sur le bouton Debug settings. La
BE électronique automobile 5e année ESE
33
fenêtre ci-dessous s'ouvre. Si le projet a été correctement défini et la mémoire cible
correctement sélectionnée, vous n'aurez pas besoin de changer les paramètres. En cas
d'erreurs lors du téléversement du programme sur la cible, contrôler les paramètres
suivants :
o C/C++application : le fichier .elf correspond-il bien à la mémoire cible visée
(RAM ou Flash) ?
o Target settings : le moyen de connexion vise t-il la bonne mémoire cible (RAM
ou Flash) ?
� Pour lancer le téléversement de l'exécutable dans la mémoire du microcontrôleur et
lancer le debug in-situ, cliquez sur le bouton Debug dans l'onglet de commande. Si
la carte démo est correctement alimentée et connectée, le programme charge
l'exécutable et le Perspective Switch est en mode Debug in-situ.
� La fenêtre ci-dessous s'ouvre.
BE électronique automobile 5e année ESE
34
Onglet debug
Code source
Contenu mémoire
Console
Barre d’outils
� La barre d’outils permet de réaliser différents modes d’exécution (run, pas à pas), de
suspendre et d'arrêter l’exécution. Plusieurs points d’arrêt peuvent être inclus par un
double clic dans la fenêtre Code Source au niveau de l’instruction où l’on souhaite
arrêter l’exécution.
� L'onglet Contenu mémoire permet d'avoir accès au contenu des variables, registres
internes et de manière générale de toute la mémoire.
� Le debug in-situ nécessite le placement de points d'arrêt pour valider l'exécution du
programme, la mise à jour de variables et du contenu des registres, le passage par des
routines d'interruption … Pour ajouter un point d'arrêt, placez la souris à gauche des
lignes du code source, faites un clic droit et sélectionnez Add Breakpoint ou
Ctrl+double clic. Il est supprimé en cliquant sur Toggle Breakpoint. Il est désactivé
avec Disable breakpoint et réactivé avec Enable Breakpoint.
� Une fois l'opération de Debug effectué, pour revenir au développement du code source,
vous pouvez basculer sur la vue C/C++
dans le Perspective Switch.
� Pour fermer un projet, cliquez dans la barre de menus sur Project > Close Project.
Pour le supprimer de l'onglet projet, clic droit sur le nom du projet puis Delete.
� Pour ouvrir un projet existant, vous pouvez cliquer sur File > Import ou le
bouton Import project.
BE électronique automobile 5e année ESE
35
4. Exemples de codes sources - Librairie Afin de prendre en main le microcontrôleur, vous pouvez télécharger la note d’application
AN2865 – « Qorivva Simple Cookbook» sur le site de NXP. Ce document vous propose
plusieurs exemples de codes sources pour les microcontrôleurs de la famille MPC5500 et 5600.
Sur le site http://www.alexandre-boyer.fr/enseignements.htm vous trouverez aussi quelques
exemples de codes sources adaptés au starter kit TRK-MPC5606B
(exemples_codes_sources_MPC5606B.zip). Ci-dessous, une liste des programmes fournis dans
ce fichiers.
exemples_codes_sources_simples avec le MPC5606B : ADC_CTU_PIT3 conversion analogique-numérique du signal délivré par le
photorécepteur du starter kit TRK-MPC5606B. L’acquisition est
cadencée via le CTU, par le débordement du timer PIT3. CAN_receive Programme basique de configuration du module FlexCAN en réception
(CAN1). Le SBC est placé en mode Debug et l’interface CAN est
activée via une commande SPI. CAN_transmit programme basique de configuration du module FlexCAN en
émission (CAN1). L’émission sur le bus CAN est cadencée par le
timer1. Le SBC est placé en mode Debug et l’interface CAN est
activée via une commande SPI. DSPI_command_send envoi d’une commande sur le bus SPI (DSPI1). EIRQ_light_LED allumage des 4 indicateurs lumineux du starter kit TRK-MPC5606B
lors d’un appui sur l’interrupteur SW1-3, connectée à une entrée EIRQ
(external interrupt request).
OPWM_ch22_ch23 configuration de 2 sorties PWM (module eMIOS). L’horloge système
est délivrée par la FM-PLL et sa fréquence est de 45 MHz. Les 2
canaux PWM commutent à 1 KHz avec un rapport cyclique de 50 et
25 % respectivement.
switch_LEDS_1Hz clignotement toutes les secondes des 4 indicateurs lumineux du starter
kit TRK-MPC5606B. L’opération est synchronisée par le débordement
du timer PIT1. L’horloge système est délivrée par l’oscillateur à quartz
(fréquence bus = 8 MHz).
switch_LEDS_1Hz_PLL clignotement toutes les secondes des 4 indicateurs lumineux du starter
kit TRK-MPC5606B. L’opération est synchronisée par le débordement
du timer PIT1. L’horloge système est délivrée par la FM-PLL
(fréquence bus = 45 MHz).
Le projet Demo_cluster_v2.zip vous donne un exemple de code source tournant sur le
MPC5645S et activant certaines fonctionnalités du cluster d’instrumentation.