35
BE électronique automobile 5 e année ESE Bureau d’étude Electronique Automobile http://www.alexandre-boyer.fr Alexandre Boyer Patrick Tounsi 5 e année ESE Octobre 2017

Bureau d’étude Electronique Automobile - Alexandre …alexandre-boyer.fr/alex/enseignement/enonce BE automobile 5SE_2017... · BE électronique automobile 5 e année ESE 3 I -

  • Upload
    phungtu

  • View
    218

  • Download
    0

Embed Size (px)

Citation preview

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

[email protected].

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

29

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.