https://erika.tuxfamily.org/wiki/index.php?title=Special:Contributions&feed=atom&limit=500&target=FrancescoErikaWiki - User contributions [en]2024-03-29T08:52:33ZFrom ErikaWikiMediaWiki 1.16.4https://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-13T09:29:01Z<p>Francesco: /* Running the demo with PCAN-View */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard). A demo showing a basic use-case of CCP protocol is available on the Erika kernel and can be chosen as template in RT-druid IDE.<br />
<br />
== Demo application ==<br />
<br />
To test the demo from RT-Druid IDE, please follow this sequence of operations:<br />
<br />
* File -> New -> "Rt Druid Oil and C/C++ projects"<br />
* Chose a name for your project and then press "Next"<br />
* set a flag on "Create a project using one of these templates"<br />
* Chose e200zx -> Leopard -> CCP_demo<br />
* Press "Finish"<br />
<br />
== Running the demo with PCAN-View ==<br />
<br />
* The CAN-dongle currently adopted for Erika CCP demo is PCAN-USB developed by Peak-System. Useful details can be found at:<br />
http://www.peak-system.com/PCAN-USB.199.0.html?&L=1<br />
* In order to provide a easy to use setup to test the demo a PCAN-View configuration file is provided by Erika distribution. It can be found in the Erika distribution at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/PCAN_CCP_TEST_LEOPARD_ADC.xmt<br />
<br />
Note: PCAN-View (the CAN tool provided by Peak System to monitor a CAN network) can be found at:<br />
http://www.peak-system.com/PCAN-View.242.0.html?&L=1 <br />
<br />
* Additional information about the demo can be found in the related readme.txt file at: =<br />
/erika/examples/ppc/templates/leopard/CCP_demo/readme.txt<br />
<br />
* Connection between PCAN-USB and Leopard EVB<br />
details about connection are shown in the readme.txt file. <br />
<br />
* On PCAN_view side: chose 500Kb speed and then press "OK". The following snapshot shown the scenario.<br />
<br />
[[Image:ppp.png]]<br />
<br />
* from PCAN-View interface press "Open File", then chose PCAN_CCP_TEST_LEOPARD_ADC.xmt file present in the CCP_demo directory, press "OK"<br />
<br />
A snapshot of the scenario with the configuration provided by .xmt file just mentioned is shown below.<br />
<br />
[[Image:ppp3.png]]<br />
<br />
To send a message simply double-click on message-ID.<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
Additional notes: a demo using Leopard and CCP protocol to monitor a variable can be found under "examples/ppc/templates/leopard/ccp_leopard", while CCP implementation is under "contrib/Ccp"<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=File:Ppp3.pngFile:Ppp3.png2014-11-13T09:27:08Z<p>Francesco: </p>
<hr />
<div></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-13T09:26:49Z<p>Francesco: /* Running the demo with PCAN-View */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard). A demo showing a basic use-case of CCP protocol is available on the Erika kernel and can be chosen as template in RT-druid IDE.<br />
<br />
== Demo application ==<br />
<br />
To test the demo from RT-Druid IDE, please follow this sequence of operations:<br />
<br />
* File -> New -> "Rt Druid Oil and C/C++ projects"<br />
* Chose a name for your project and then press "Next"<br />
* set a flag on "Create a project using one of these templates"<br />
* Chose e200zx -> Leopard -> CCP_demo<br />
* Press "Finish"<br />
<br />
== Running the demo with PCAN-View ==<br />
<br />
* The CAN-dongle currently adopted for Erika CCP demo is PCAN-USB developed by Peak-System. Useful details can be found at:<br />
http://www.peak-system.com/PCAN-USB.199.0.html?&L=1<br />
* In order to provide a easy to use setup to test the demo a PCAN-View configuration file is provided by Erika distribution. It can be found in the Erika distribution at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/PCAN_CCP_TEST_LEOPARD_ADC.xmt<br />
<br />
Note: PCAN-View (the CAN tool provided by Peak System to monitor a CAN network) can be found at:<br />
http://www.peak-system.com/PCAN-View.242.0.html?&L=1 <br />
<br />
* Additional information about the demo can be found in the related readme.txt file at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/readme.txt<br />
<br />
* Connection between PCAN-USB and Leopard ECB<br />
details about connection are shown in the readme.txt file. On PCAN_view side:<br />
<br />
* chose 500Kb speed and then press "OK". The following snapshot shown the scenario.<br />
<br />
[[Image:ppp.png]]<br />
<br />
* from PCAN-View interface press "Open File", then chose PCAN_CCP_TEST_LEOPARD_ADC.xmt file present in the CCP_demo directory, press "OK"<br />
<br />
A snapshot of the scenario with the configuration provided by .xmt file just mentioned is shown below.<br />
<br />
[[Image:ppp3.png]]<br />
<br />
To send a message simply double-click on message-ID.<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
Additional notes: a demo using Leopard and CCP protocol to monitor a variable can be found under "examples/ppc/templates/leopard/ccp_leopard", while CCP implementation is under "contrib/Ccp"<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-13T09:25:12Z<p>Francesco: /* Running the demo with PCAN-View */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard). A demo showing a basic use-case of CCP protocol is available on the Erika kernel and can be chosen as template in RT-druid IDE.<br />
<br />
== Demo application ==<br />
<br />
To test the demo from RT-Druid IDE, please follow this sequence of operations:<br />
<br />
* File -> New -> "Rt Druid Oil and C/C++ projects"<br />
* Chose a name for your project and then press "Next"<br />
* set a flag on "Create a project using one of these templates"<br />
* Chose e200zx -> Leopard -> CCP_demo<br />
* Press "Finish"<br />
<br />
== Running the demo with PCAN-View ==<br />
<br />
* The CAN-dongle currently adopted for Erika CCP demo is PCAN-USB developed by Peak-System. Useful details can be found at:<br />
http://www.peak-system.com/PCAN-USB.199.0.html?&L=1<br />
* In order to provide a easy to use setup to test the demo a PCAN-View configuration file is provided by Erika distribution. It can be found in the Erika distribution at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/PCAN_CCP_TEST_LEOPARD_ADC.xmt<br />
<br />
Note: PCAN-View (the CAN tool provided by Peak System to monitor a CAN network) can be found at:<br />
http://www.peak-system.com/PCAN-View.242.0.html?&L=1 <br />
<br />
* Additional information about the demo can be found in the related readme.txt file at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/readme.txt<br />
<br />
* Connection between PCAN-USB and Leopard ECB<br />
details about connection are shown in the readme.txt file. On PCAN_view side:<br />
<br />
* chose 500Kb speed and then press "OK". The following snapshot shown the scenario.<br />
<br />
[[Image:ppp.png]]<br />
<br />
* from PCAN-View interface press "Open File", then chose PCAN_CCP_TEST_LEOPARD_ADC.xmt file present in the CCP_demo directory, press "OK"<br />
<br />
A snapshot of the scenario with the configuration provided by .xmt file just mentioned is shown below.<br />
<br />
[[Image:ppp2.png]]<br />
<br />
To send a message simply double-click on message-ID.<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
Additional notes: a demo using Leopard and CCP protocol to monitor a variable can be found under "examples/ppc/templates/leopard/ccp_leopard", while CCP implementation is under "contrib/Ccp"<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=File:Ppp2.pngFile:Ppp2.png2014-11-13T09:23:40Z<p>Francesco: </p>
<hr />
<div></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-13T09:22:33Z<p>Francesco: /* Running the demo with PCAN-View */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard). A demo showing a basic use-case of CCP protocol is available on the Erika kernel and can be chosen as template in RT-druid IDE.<br />
<br />
== Demo application ==<br />
<br />
To test the demo from RT-Druid IDE, please follow this sequence of operations:<br />
<br />
* File -> New -> "Rt Druid Oil and C/C++ projects"<br />
* Chose a name for your project and then press "Next"<br />
* set a flag on "Create a project using one of these templates"<br />
* Chose e200zx -> Leopard -> CCP_demo<br />
* Press "Finish"<br />
<br />
== Running the demo with PCAN-View ==<br />
<br />
* The CAN-dongle currently adopted for Erika CCP demo is PCAN-USB developed by Peak-System. Useful details can be found at:<br />
http://www.peak-system.com/PCAN-USB.199.0.html?&L=1<br />
* In order to provide a easy to use setup to test the demo a PCAN-View configuration file is provided by Erika distribution. It can be found in the Erika distribution at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/PCAN_CCP_TEST_LEOPARD_ADC.xmt<br />
<br />
Note: PCAN-View (the CAN tool provided by Peak System to monitor a CAN network) can be found at:<br />
http://www.peak-system.com/PCAN-View.242.0.html?&L=1 <br />
<br />
* Additional information about the demo can be found in the related readme.txt file at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/readme.txt<br />
<br />
* Connection between PCAN-USB and Leopard ECB<br />
details about connection are shown in the readme.txt file. On PCAN_view side:<br />
<br />
* chose 500Kb speed and then press "OK". The following snapshot shown the scenario.<br />
<br />
[[Image:ppp.png]]<br />
<br />
* from PCAN-View interface press "Open File", then chose PCAN_CCP_TEST_LEOPARD_ADC.xmt file present in the CCP_demo directory, press "OK"<br />
<br />
A snapshot of the scenario with the configuration provided by .xmt file just mentioned is shown below.<br />
<br />
[[Image:ppp2.png]]<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
Additional notes: a demo using Leopard and CCP protocol to monitor a variable can be found under "examples/ppc/templates/leopard/ccp_leopard", while CCP implementation is under "contrib/Ccp"<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=File:Ppp.pngFile:Ppp.png2014-11-13T09:20:18Z<p>Francesco: </p>
<hr />
<div></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-13T09:19:13Z<p>Francesco: /* Running the demo with PCAN-View */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard). A demo showing a basic use-case of CCP protocol is available on the Erika kernel and can be chosen as template in RT-druid IDE.<br />
<br />
== Demo application ==<br />
<br />
To test the demo from RT-Druid IDE, please follow this sequence of operations:<br />
<br />
* File -> New -> "Rt Druid Oil and C/C++ projects"<br />
* Chose a name for your project and then press "Next"<br />
* set a flag on "Create a project using one of these templates"<br />
* Chose e200zx -> Leopard -> CCP_demo<br />
* Press "Finish"<br />
<br />
== Running the demo with PCAN-View ==<br />
<br />
* The CAN-dongle currently adopted for Erika CCP demo is PCAN-USB developed by Peak-System. Useful details can be found at:<br />
http://www.peak-system.com/PCAN-USB.199.0.html?&L=1<br />
* In order to provide a easy to use setup to test the demo a PCAN-View configuration file is provided by Erika distribution. It can be found in the Erika distribution at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/PCAN_CCP_TEST_LEOPARD_ADC.xmt<br />
<br />
Note: PCAN-View (the CAN tool provided by Peak System to monitor a CAN network) can be found at:<br />
http://www.peak-system.com/PCAN-View.242.0.html?&L=1 <br />
<br />
* Additional information about the demo can be found in the related readme.txt file at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/readme.txt<br />
<br />
* Connection between PCAN-USB and Leopard ECB<br />
details about connection are shown in the readme.txt file. On PCAN_view side:<br />
<br />
* chose 500Kb speed and then press "OK".<br />
* from PCAN-View interface press "Open File", then chose PCAN_CCP_TEST_LEOPARD_ADC.xmt file present in the CCP_demo directory, press "OK"<br />
<br />
A snapshot of the scenario is shown in the following picture.<br />
<br />
[[Image:ppp.png]]<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
Additional notes: a demo using Leopard and CCP protocol to monitor a variable can be found under "examples/ppc/templates/leopard/ccp_leopard", while CCP implementation is under "contrib/Ccp"<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-13T09:18:20Z<p>Francesco: /* Running the demo with PCAN-View */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard). A demo showing a basic use-case of CCP protocol is available on the Erika kernel and can be chosen as template in RT-druid IDE.<br />
<br />
== Demo application ==<br />
<br />
To test the demo from RT-Druid IDE, please follow this sequence of operations:<br />
<br />
* File -> New -> "Rt Druid Oil and C/C++ projects"<br />
* Chose a name for your project and then press "Next"<br />
* set a flag on "Create a project using one of these templates"<br />
* Chose e200zx -> Leopard -> CCP_demo<br />
* Press "Finish"<br />
<br />
== Running the demo with PCAN-View ==<br />
<br />
* The CAN-dongle currently adopted for Erika CCP demo is PCAN-USB developed by Peak-System. Useful details can be found at:<br />
http://www.peak-system.com/PCAN-USB.199.0.html?&L=1<br />
* In order to provide a easy to use setup to test the demo a PCAN-View configuration file is provided by Erika distribution. It can be found in the Erika distribution at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/PCAN_CCP_TEST_LEOPARD_ADC.xmt<br />
<br />
Note: PCAN-View (the CAN tool provided by Peak System to monitor a CAN network) can be found at:<br />
http://www.peak-system.com/PCAN-View.242.0.html?&L=1 <br />
<br />
* Additional information about the demo can be found in the related readme.txt file at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/readme.txt<br />
<br />
* Connection between PCAN-USB and Leopard ECB<br />
details about connection are shown in the readme.txt file. On PCAN_view side:<br />
<br />
* chose 500Kb speed and then press "OK".<br />
* from PCAN-View interface press "Open File", then chose PCAN_CCP_TEST_LEOPARD_ADC.xmt file present in the CCP_demo directory, press "OK"<br />
<br />
A snapshot of the scenario is shown in the following picture.<br />
<br />
[[Image:flash_map_prova.png]]<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
Additional notes: a demo using Leopard and CCP protocol to monitor a variable can be found under "examples/ppc/templates/leopard/ccp_leopard", while CCP implementation is under "contrib/Ccp"<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-13T09:17:22Z<p>Francesco: /* Running the demo with PCAN-View */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard). A demo showing a basic use-case of CCP protocol is available on the Erika kernel and can be chosen as template in RT-druid IDE.<br />
<br />
== Demo application ==<br />
<br />
To test the demo from RT-Druid IDE, please follow this sequence of operations:<br />
<br />
* File -> New -> "Rt Druid Oil and C/C++ projects"<br />
* Chose a name for your project and then press "Next"<br />
* set a flag on "Create a project using one of these templates"<br />
* Chose e200zx -> Leopard -> CCP_demo<br />
* Press "Finish"<br />
<br />
== Running the demo with PCAN-View ==<br />
<br />
* The CAN-dongle currently adopted for Erika CCP demo is PCAN-USB developed by Peak-System. Useful details can be found at:<br />
http://www.peak-system.com/PCAN-USB.199.0.html?&L=1<br />
* In order to provide a easy to use setup to test the demo a PCAN-View configuration file is provided by Erika distribution. It can be found in the Erika distribution at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/PCAN_CCP_TEST_LEOPARD_ADC.xmt<br />
<br />
Note: PCAN-View (the CAN tool provided by Peak System to monitor a CAN network) can be found at:<br />
http://www.peak-system.com/PCAN-View.242.0.html?&L=1 <br />
<br />
* Additional information about the demo can be found in the related readme.txt file at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/readme.txt<br />
<br />
* Connection between PCAN-USB and Leopard ECB<br />
details about connection are shown in the readme.txt file. On PCAN_view side:<br />
<br />
* chose 500Kb speed and then press "OK".<br />
* from PCAN-View interface press "Open File", then chose PCAN_CCP_TEST_LEOPARD_ADC.xmt file present in the CCP_demo directory, press "OK"<br />
<br />
A snapshot of the scenario is shown in the following picture.<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
Additional notes: a demo using Leopard and CCP protocol to monitor a variable can be found under "examples/ppc/templates/leopard/ccp_leopard", while CCP implementation is under "contrib/Ccp"<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-13T09:16:53Z<p>Francesco: /* Running the demo with PCAN-View */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard). A demo showing a basic use-case of CCP protocol is available on the Erika kernel and can be chosen as template in RT-druid IDE.<br />
<br />
== Demo application ==<br />
<br />
To test the demo from RT-Druid IDE, please follow this sequence of operations:<br />
<br />
* File -> New -> "Rt Druid Oil and C/C++ projects"<br />
* Chose a name for your project and then press "Next"<br />
* set a flag on "Create a project using one of these templates"<br />
* Chose e200zx -> Leopard -> CCP_demo<br />
* Press "Finish"<br />
<br />
== Running the demo with PCAN-View ==<br />
<br />
* The CAN-dongle currently adopted for Erika CCP demo is PCAN-USB developed by Peak-System. Useful details can be found at:<br />
http://www.peak-system.com/PCAN-USB.199.0.html?&L=1<br />
* In order to provide a easy to use setup to test the demo a PCAN-View configuration file is provided by Erika distribution. It can be found in the Erika distribution at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/PCAN_CCP_TEST_LEOPARD_ADC.xmt<br />
<br />
Note: PCAN-View (the CAN tool provided by Peak System to monitor a CAN network) can be found at:<br />
http://www.peak-system.com/PCAN-View.242.0.html?&L=1 <br />
<br />
* a reference to the readme containing the CCP messages<br />
Additional information about the demo can be found in the related readme.txt file at:<br />
/erika/examples/ppc/templates/leopard/CCP_demo/readme.txt<br />
<br />
* Connection between PCAN-USB and Leopard ECB<br />
<br />
details about connection are shown in the readme.txt file. On PCAN_view side:<br />
<br />
* chose 500Kb speed and then press "OK".<br />
* from PCAN-View interface press "Open File", then chose PCAN_CCP_TEST_LEOPARD_ADC.xmt file present in the CCP_demo directory, press "OK"<br />
<br />
A snapshot of the scenario is shown in the following picture.<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
Additional notes: a demo using Leopard and CCP protocol to monitor a variable can be found under "examples/ppc/templates/leopard/ccp_leopard", while CCP implementation is under "contrib/Ccp"<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-13T08:53:19Z<p>Francesco: /* Subset of the standard implemented */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard). A demo showing a basic use-case of CCP protocol is available on the Erika kernel and can be chosen as template in RT-druid IDE.<br />
<br />
To test the demo from RT-Druid IDE, please follow this sequence of operations:<br />
<br />
* File -> New -> "Rt Druid Oil and C/C++ projects"<br />
* Chose a name for your project and then press "Next"<br />
* set a flag on "Create a project using one of these templates"<br />
* Chose e200zx -> Leopard -> CCP_demo<br />
* Press "Finish"<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
Additional notes: a demo using Leopard and CCP protocol to monitor a variable can be found under "examples/ppc/templates/leopard/ccp_leopard", while CCP implementation is under "contrib/Ccp"<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-13T08:50:28Z<p>Francesco: /* Target supported */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =A<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard). A demo showing a basic use-case of CCP protocol is available on the Erika kernel and can be chosen as template in RT-druid IDE.<br />
<br />
To test the demo from RT-Druid IDE, please follow this sequence of operations:<br />
<br />
- File -> New -> "Rt Druid Oil and C/C++ projects"<br />
- Chose a name for your project and then press "Next"<br />
- set a flag on "Create a project using one of these templates"<br />
- Chose e200zx -> Leopard -> CCP_demo<br />
- Press "Finish"<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
Additional notes: a demo using Leopard and CCP protocol to monitor a variable can be found under "examples/ppc/templates/leopard/ccp_leopard", while CCP implementation is under "contrib/Ccp"<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=ERIKA_Enterprise_Device_Drivers_for_Leopard_MPC5643LERIKA Enterprise Device Drivers for Leopard MPC5643L2014-11-10T13:46:47Z<p>Francesco: /* Architecture description (Ref. MPC5643LRM Rev. 9 12 Mar 2012) */</p>
<hr />
<div>= Backlog =<br />
<br />
Il backlog e' su google docs su [https://docs.google.com/spreadsheet/ccc?key=0AsS2INzQeayzdG1yNUVTWUVMSHFtcVJ6ejJnVnh2eHc questo link] --- NO LONGER IN USE ---<br />
<br />
= Architecture description (Ref. Freescale MPC5643LRM Rev. 9 12 Mar 2012) =<br />
<br />
The Qorivva MPC5643L microcontroller is based on the Power Architecture. All MPC5643L devices are built around a dual-core safety platform, each core is a member of the e200z4 Power Architecture family. Lock step Redundancy Checking Units are implemented at each output of this Sphere of Replication (SoR). ECC is available for on-chip SRAM and flash memories. A programmable fault collection and control unit monitors the integrity status of the device and provides flexible safe state control. The peripheral set provides high-end electrical motor control capability with very low CPU intervention due to the on-chip cross-triggering unit (CTU).<br />
<br />
= Flash Usage =<br />
<br />
There are three address spaces featuring Flash memory of MPC5643L:<br />
<br />
* Low address space (256 KB)<br />
* Mid address space (256 KB)<br />
* High address space (512 KB)<br />
<br />
The MPC5643L flash memory usage has been managed as follow.<br />
<br />
* Block L0 (0x0 - 0x00004000) hosts the boot key of the microcontroler. MPC5643L has several boot sectors, Each boot sector in the flash memory contains at offset 0x00 the Reset Configuration Half-Word (RCHW) that is composed by 2 parts. First part is used to mark this boot sector as "bootable" (0x5A), second part to set VLE/BOOK E mode:<br />
<br />
# 0x15a0000 if the microcontroller runs in "VLE" mode<br />
# 0x05a0000 if the microcontroller runs in "BOOK E" mode<br />
<br />
RCHW is immediately followed by the reset vector of the microcontroller (the address from the microncontroller starts from).<br />
<br />
* Block L1, L2 and L3 (0x00004000 - 0x00020000) hosts Non-Volatile-RAM (NVRAM) data. The policy in charge of managing this flash area is explained in section NVRAM.<br />
* Block L4 and L5 (0x00020000 - 0x00040000) hosts boot code. The content of this flash area is explained in section BOOT.<br />
* Block M0 and M1 (0x00040000 - 0x00080000) hosts calibrations data. The policy in charge of managing this flash area is explained in section CALIBRATIONS.<br />
* Block H0 and H1 (0x00080000 - 0x000C0000) hosts application code. The content of this flash area is explained in section APPLICATION.<br />
<br />
Flash memory is devised as follow:<br />
<br />
[[Image:Flash_map_prova.png]]<br />
<br />
== BOOT Flash area ==<br />
<br />
This area will be used to locate Bootloader code. Not provided in this version<br />
<br />
= APPLICATION Flash area =<br />
<br />
Application Flash area hosts user application, drivers and Erika OS.<br />
<br />
== Erika OS ==<br />
<br />
Erika has been provide with the following configurations:<br />
<br />
* '''Single Core (DPM mode)'''. The main feaure of this configuration is that the user has 128 Kbytes of SRAM memory available divided in two memory banks (0x40000000 - 0x4000FFFF and 0x50000000 - 0x5000FFFF). This configuration can be executed from SRAM and from FLASH. The flags used to enable SRAM configurations is: __E200ZX_EXECUTE_FROM_RAM__, if it is not used, FLASH configuration is enabled by default. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:sram_dpm.png]]<br />
<br />
<br />
* '''Single core (Lock-step)'''. The main feaure of this configuration is that the user has 128 Kbytes of SRAM memory available (0x40000000 - 0x0001FFFF). This configuration can be executed from SRAM and from FLASH. In order to enable Lock-step mode the LOCK_STEP flag has to be enabled. This flag has to be combined with __E200ZX_EXECUTE_FROM_RAM__ if the target has to execute from SRAM. If only LOCK_STEP is enabled the target executes from Flash. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:sram_lock.png]]<br />
<br />
<br />
* '''Multicore (DPM mode)'''. The main feature of this configuration is that the user has 64 Kbytes of SRAM memory available for each core. In particular the first 64 Kbytes-bank of SRAM memory (0x40000000 - 0x4000FFFF) is allocated to the master core, this memory area also hosts data shared by both cores. The second 64 Kbytes-bank of SRAM memory (0x50000000 - 0x5000FFFF) is allocated to the slave core. In order to enable this configuration the flag __MSRP__ has to be defined. It has to be combined with __E200ZX_EXECUTE_FROM_RAM__ to have a system running from SRAM. If this flag is not enabled, hence the multicore application is configured to run from Flash. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:multi_dpm.png]]<br />
<br />
<br />
'''Additional notes about Erika-multicore in MPC5643L'''<br />
<br />
Erika uses hardware semaphores to guarantee data coherence between master and slave cores. It also used a signalling system based on software interrupts to provides basic inter-core synchronisation mechanism. MPC5643L has two SEMA4 modules, each module has 16 HW semaphores, but these semaphores are not all available by the user since they are used by the operating system to implement a barrier to synchronise both cores after boot sequence. According with these assumptions the 7-th software interrupt is used by signal mechanism and semaphore 0 and 1 of the master's SEMA4 module are used to implement synchronisation barrier, therefore they cannot be used for different purposes. All the remaining semaphores (from 2 to 15 belonging to the master's SEMA4 and all 16 belonging to the slave's SEMA4) and software interrupts (from 1 to 7 of both interrupt controllers) can be used by the user application. Notice that these limitations have to be taken into account only when the system is configured as multi-core. In single-core mode the user is free to use all software interrupts according with his needs, since boot-barrier is not enabled and inter-processor (software) interrupt are not required.<br />
<br />
== Drivers ==<br />
<br />
The implemented drivers are: CanDrv, FlashDrv, SpiDrv, Adc, Pwm and CTU. The details concerning these Drivers are reported in section Device Drivers.<br />
<br />
== User Application ==<br />
<br />
Evidence is not in charge of this part.<br />
<br />
= Board Internal Connections =<br />
<br />
This chapter provides a schema to show connections required for SPI, ADC, CAN (configured as CANDRV_NORMAL), System clock and one PWM signal (PWM0_A1).<br />
<br />
[[Image:board.png]]<br />
<br />
= Device Drivers =<br />
<br />
== Can Driver (CanDrv) ==<br />
<br />
Can Driver is based on Freescale FlexCan present in MPC5643L. Can Driver details will be provided in two distinct sections: configuration and API. Configuration section concerns Can Driver static configuration, that means that Can Driver has to be statically configured by CanCfg module (reference: sources/ApplCfg/CanCfg.c). The API section of the manual shows the set of functionalities featuring this CanDrv implemenation.<br />
<br />
=== CanDrv Configuration ===<br />
<br />
There two levels of CanDrv configuration: FlexCan level and message level. First level is used to configure Can Module with respect the following fields:<br />
<br />
* peripheralEn: it can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that the user wants to enabled or disabled the current Flexcan module. Notice that MPC5643L has two FlexCan modules.<br />
* mode: it can be CANDRV_NORMAL, CANDRV_LOOPBACK or CANDRV_OPENDRAIN. CANDRV_LOOPBACK means that FlexCan module works in loopback mode (look at Reference Manual for details. Ref: MPC5643LRM Rev. 9 12 Mar 2012), CANDRV_OPENDRAIN means that Flexcan is in open drain mode that means that user can connect two FlexCan modules available in MPC564L without the need of external connections.<br />
* autobusonEn: this field can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that the Auto-buson feature is enabled or not (look at Reference Manual for details. Ref: MPC5643LRM Rev. 9 12 Mar 2012)<br />
* peripheralFreq: this field determines FlexCan frequency. There five available values: CANDRV_1MBPS, CANDRV_500KBPS, CANDRV_250KBPS or CANDRV_125KBPS.<br />
* errorHandlingEn: it can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that user needs error handling capability.<br />
* sampleNumMode: it can be CANDRV_THREE_SAMPLE if user wants to sample the signal three times.<br />
<br />
In CW project and Integration project there are three cases (NORMAL, LOOPBACK and OPENDRAIN) characterised by their configuration parameters. LOOPBACK and OPENDRAIN cases are commented, in order to try these configurations please comment NORMAL mode and uncomment LOOPBACK or OPENDRAIN.<br />
The configuration version currently available in the repository provides FlexCan0 module enabled and FlexCan1 module disabled. All the fields of FlexCan1 are set to CANDRV_DO_NOT_CARE because peripheralEn is set to CANDRV_DISABLED. CanFlex0 is set as a 500 Kbps FlexCan module, with error handling enabled, auto-buson enabled, normal mode and three samples feature enabled.<br />
<br />
=== CanDrv API ===<br />
<br />
'''StdReturnType CanDrvInit(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Initialise canDrv component according with the features set in CanCfg module.<br />
<br />
'''void ManageCanIsr(uint8 isrSourceIndex, uint32 bufferFlags, CanChannelType canChannel);'''<br />
<br />
Input parameters are:<br />
* isrSourceIndex: is the offset in the FLAG1 register representing the isr source;<br />
* bufferFlags: the real isr source;<br />
* canChannel: represents FlexCan0 or FlexCan1<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Initialises Flexcan modules according with the user features set in CanCfg.<br />
<br />
'''StdReturnType CanTransmit(CanTxMsgIndexType msgIndex);'''<br />
<br />
Input parameters are:<br />
* msgIndex: message index taken from all message indexes defined by the user;<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
This function transmits "msgIndex" Can message. Return value of this function is the return value of CanSendManageMsg().<br />
<br />
'''StdReturnType CanPollMessage(CanRxMsgIndexType msgIndex, CanChannelType canChannel);'''<br />
<br />
Input parameters are:<br />
* msgIndex: message index taken from all message indexes defined by the user;<br />
* canChannel: FlexCan channel. It can be Flexcan0 or FlexCan1.<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
If canChannel is different fromFlexcan0 or Flexcan1, return value is STD_NOT_OK. If CanPollMessage() is called for a message for which a isr has been defined and the driver is working in INTERRUPT mode, return value is STD_NOT_OK. For all the remaining scenarios the return value is STD_OK.<br />
<br />
'''void CanDrvEnableInterrupts(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Enable Flexcan interrupts according with the CanCfg flags.<br />
<br />
'''void CanDrvDisableInterrupts(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Disable ALL FlexCan interrupts featuring ENABLED Flexcan modules.<br />
<br />
'''void CanDrvPolling(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function polls all FlexCan messages.<br />
<br />
== Spi Driver (SpiDrv) ==<br />
<br />
A simplified Spi Driver has been provide. Through this driver it is possible to use Spi Module both in Polling mode and Isr mode. APIs are defined as follow:<br />
<br />
'''void SpiTransmit(uint8 channel, uint8 chip_select, uint8 * data, uint8 length);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
* chip_select: is the cuip select (from 0 to 7).<br />
* length: is message length<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function transmits a spi message. Notice that no checks are performed on input parameters.<br />
<br />
'''StdReturnType SpiDrvInit(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
This function initialises Spi Driver according with flags present in SpiCfg module.<br />
<br />
'''void SpiPoolChannel(const uint8 channel, uint16_t * res);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
* res: is the location of the result<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function pools one Spi channel and store the result in the location pointed by res.<br />
<br />
'''uint32 SpiGetMessageLenght(const uint8 channel);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
<br />
Output parameter:<br />
* message length<br />
<br />
Description:<br />
<br />
Not still developed (NO REQUIREMENTS).<br />
<br />
== Pwm+Adc Drivers (with CTU support) ==<br />
<br />
In PWM driven systems it is important to schedule the acquisition of the state variables with respect to<br />
PWM cycle. State variables are obtained through the following peripherals: ADC, position counter (e.g.<br />
quadrature decoder, resolver and sine-cos sensor) and PWM duty cycle decoder.<br />
The cross triggering unit (CTU) is intended to completely avoid CPU involvement in the time acquisitions<br />
of state variables during the control cycle that can be the PWM cycle, the half PWM cycle or a number of<br />
PWM cycles. In such case the pre-setting of the acquisition times needs to be completed during the<br />
previous control cycle, where the actual acquisitions are to be made, and a double-buffered structure for<br />
the CTU registers is used, in order to activate the new settings at the beginning of the next control cycle.<br />
<br />
'''Problem:''' the main problem featuring this part of the application concerns ADC timing. In order to speed the acquisition up, the<br />
PWM A0 rising edge is used to trigger the Star-Of-Conversion (SOC). This means that whenever the PWM counter ramp reaches the maximum value,<br />
the CTU triggers a ADC acquisition without CPU intervention. This CTU action starts an ADC conversion at the beginning of 50 usec interval (SOC).<br />
Once the ADC conversion terminates at the End-Of-Conversion point (EOC at point 2), a ISR may be raised (but it has been disabled, since a polling strategy has<br />
been preferred). The remaining chunk of time (from EOC to the end of 50 usec), can be used for secondary activities (it is denoted as Free Bandwidth).<br />
At the end of 50-usecs interval, CTU triggers a new acquisition. Notice that the end of 50 usec represents a HARD Deadline, hence it will never being missed.<br />
<br />
[[Image:ctu.png]]<br />
<br />
'''Performance note:''' through a preliminary test, the interval of time between SOC and EOC (the red chunk) assumes a value equal to 790 PWM counter ticks (approximately 14 usec with a 120 Mhz CPU clock).<br />
<br />
=== PWM ===<br />
<br />
MPC5643L has two PWM modules, <br />
A simplified PWM Driver has been provide. Through this driver it is possible to access PWM basic functionalities. MPC5643L has two PWM modules, each PWM module has four PWM devices, for this application only a subset of FlexPWM0 module is used to generate three PWM signals: PWM0_A0, PWM0_A1 and PWM0_A2. APIs are defined as follow:<br />
<br />
'''void InitFlexPWM0(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function initialises FlexPWM0.<br />
<br />
'''void PWM0_AX_load_new_rising_edge(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: match value of the rising edge of X sub-module (X=0,1,2)<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function sets the match value (for rising edge) of PWM0_AX sub-module (X=0,1,2).<br />
<br />
'''void PWM0_AX_load_new_falling_edge(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: match value of the falling edge of X sub-module (X=0,1,2)<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function sets the match value (for falling edge) of PWM0_AX sub-module (X=0,1,2).<br />
<br />
=== ADC ===<br />
<br />
The Analog to Digital Converter (ADC) is a 12 bit Successive Approximation register (SAR) ADC with a mixed capacitive/resistive DAC. This device includes two ADC modules, referred to as ADC_0 and ADC_1. A conversion can be triggered by<br />
software or hardware (CTU), the solution selected for this application is the second one, that is based on CTU support. Currently the system starts the acquisition of 8 different ADC signals of the ADC_0 module as soon as CTU triggers the ADC_0 module. This happens whenever the internal counter of the PWM0 module matches its maximum value.<br />
<br />
External ADC channels:<br />
* 9 external channels on ADC_0 (channels 0..8)<br />
* 9 external channels on ADC_1 (channels 0..8)<br />
* 4 external channels shared between ADC_0 and ADC_1 (channels 11..14)<br />
<br />
This the list of ADC Driver APIs:<br />
<br />
'''StdReturnType InitADC(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
This function initialises ADC_0 module according with flags present in sources/ApplCfg/AdcCfg/AdcCfg.c. Data structure featuring ADC_0 and ADC_1 is adcConfContainer[2], it is characterised by the followinh data fields:<br />
<br />
* peripheralEn: it can be ADC_ENABLED/ADC_DISABLED to enable/disable ADC_0<br />
* peripheralFreq: it can be ADC_HALF_SYS_FREQ for a working freq. equal to 1/2 of the system freq. It can be ADC_SYS_FREQ if the user requires a working freq. equal to the system freq.<br />
* adcCommandConfigPtr: pointer to a CTU command list.<br />
<br />
<br />
'''uint8 AdcPollChannel(const uint8 adcModule, const uint8 channel)'''<br />
<br />
Input parameters are:<br />
* adcModule: it can be ADC__0 or ADC__1<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function pools the couple "ADC module and channel" represented by adcModule and channel.<br />
<br />
=== CTU (Cross Triggering Unit) ===<br />
<br />
The CTU in this context is used to synchronises the Star-Of-Conversion of the ADC0 channel to the PWM0 counter rising edge , this has been guaranteed without any CPU intervention. CTU has to be initialised in order to accomplish this requirement. All the initialization parameters are collected in one API:<br />
<br />
'''void InitCTU(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function initialises CTU to address the problem shown at the beginning of section "Pwm+Adc Drivers (with CTU support)".<br />
<br />
== Stm Driver ==<br />
<br />
Driver supporting basic STM (System Timer Module) functionalities. In the Erika repository is also provided a AUTOSAR-like version of STM Driver. This is the list of APIs featuring this STM basic driver:<br />
<br />
'''void mpc5643l_stm_freeze_on(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Enable freeze mode option of STM timer. If enabled, when system switches to debug mode, timer stops running.<br />
<br />
'''void mpc5643l_stm_freeze_off(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Disable freeze mode option of STM timer. If disabled, when system switches to debug mode, timer continues to increment.<br />
<br />
'''void mpc5643l_stm_set_prescaler(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: prescaler value<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function set STM prescaler<br />
<br />
'''void mpc5643l_stm_select_channel(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be use<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function select STM timer to use<br />
<br />
'''void mpc5643l_stm_unselect_channel(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function deselects a specific STM channel.<br />
<br />
'''void mpc5643l_stm_channel_cmp(unsigned int ch, unsigned int val);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
* val: comparator value<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This set a comparator for a specific STM channel<br />
<br />
'''void mpc5643l_stm_clear_int(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Clear interrupt for a specific STM channel<br />
<br />
'''void mpc5643l_stm_set_counter(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: set the counter of the STM<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Set STM counter value<br />
<br />
'''void mpc5643l_stm_enable(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Enable STM<br />
<br />
'''void mpc5643l_stm_disable(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Disable STM<br />
<br />
= Lauterbach Support =<br />
<br />
The reference debugging solution for MPC5643L is Lauterbach. In the Erika tree (look at pkg/mcu/freescale_mpc5643l/cfg) is collected a set of Lauterbach sripts for single and multicore configurations. Such a scripts also provide support for execution from SRAM and Flash, in VLE and BookE mode. MPC5643L provides the capability to work in lock-step mode, for this reason a script to pass from/to DPM/lock-step mode is provide (set_lsm_dpm.cmm). To launch this script, user have to launch Lauterbach Tracer first (for instance by editing "t32mppc" in Linux prompt, or equivalent command under Window), and then editing "do set_lsm_dpm.cmm" in the Lauterbach command prompt. This script provides several functionalities, but the only functionality addressed by this manual is the one to switch from/to lock-step/DPM mode. Once the user launches this script the following window appears:<br />
<br />
<br />
[[Image:set_lock_step.png]]<br />
<br />
<br />
Red box shows two buttons to select lock-step or DPM mode. For instance, in this case we have a system set as DPM, if we would like to switch to LSM mode, we have to press the LSM button, and then press "PROGRAM". After this action, a confirmation window will be shown, press "YES" to confirm:<br />
<br />
<br />
[[Image:lock_step_ok_button.png]]<br />
<br />
<br />
If the programming task is successfully accomplished, the following window will be shown. Press "OK" to terminate the script.<br />
<br />
<br />
[[Image:lock_step_ok_message.png]]<br />
<br />
<br />
<span style="color:#ff0000"> IMPORTANT NOTE: </span> in order to make the switch-mode effective, a power-cycle has to be done. Therefore power your board off, and then power it on.</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=ERIKA_Enterprise_Device_Drivers_for_Leopard_MPC5643LERIKA Enterprise Device Drivers for Leopard MPC5643L2014-11-10T13:43:38Z<p>Francesco: /* Project structure */</p>
<hr />
<div>= Backlog =<br />
<br />
Il backlog e' su google docs su [https://docs.google.com/spreadsheet/ccc?key=0AsS2INzQeayzdG1yNUVTWUVMSHFtcVJ6ejJnVnh2eHc questo link] --- NO LONGER IN USE ---<br />
<br />
= Architecture description (Ref. MPC5643LRM Rev. 9 12 Mar 2012) =<br />
<br />
The Qorivva MPC5643L microcontroller is based on the Power Architecture. All MPC5643L devices are built around a dual-core safety platform, each core is a member of the e200z4 Power Architecture family. Lock step Redundancy Checking Units are implemented at each output of this Sphere of Replication (SoR). ECC is available for on-chip SRAM and flash memories. A programmable fault collection and control unit monitors the integrity status of the device and provides flexible safe state control. The peripheral set provides high-end electrical motor control capability with very low CPU intervention due to the on-chip cross-triggering unit (CTU).<br />
<br />
= Flash Usage =<br />
<br />
There are three address spaces featuring Flash memory of MPC5643L:<br />
<br />
* Low address space (256 KB)<br />
* Mid address space (256 KB)<br />
* High address space (512 KB)<br />
<br />
The MPC5643L flash memory usage has been managed as follow.<br />
<br />
* Block L0 (0x0 - 0x00004000) hosts the boot key of the microcontroler. MPC5643L has several boot sectors, Each boot sector in the flash memory contains at offset 0x00 the Reset Configuration Half-Word (RCHW) that is composed by 2 parts. First part is used to mark this boot sector as "bootable" (0x5A), second part to set VLE/BOOK E mode:<br />
<br />
# 0x15a0000 if the microcontroller runs in "VLE" mode<br />
# 0x05a0000 if the microcontroller runs in "BOOK E" mode<br />
<br />
RCHW is immediately followed by the reset vector of the microcontroller (the address from the microncontroller starts from).<br />
<br />
* Block L1, L2 and L3 (0x00004000 - 0x00020000) hosts Non-Volatile-RAM (NVRAM) data. The policy in charge of managing this flash area is explained in section NVRAM.<br />
* Block L4 and L5 (0x00020000 - 0x00040000) hosts boot code. The content of this flash area is explained in section BOOT.<br />
* Block M0 and M1 (0x00040000 - 0x00080000) hosts calibrations data. The policy in charge of managing this flash area is explained in section CALIBRATIONS.<br />
* Block H0 and H1 (0x00080000 - 0x000C0000) hosts application code. The content of this flash area is explained in section APPLICATION.<br />
<br />
Flash memory is devised as follow:<br />
<br />
[[Image:Flash_map_prova.png]]<br />
<br />
== BOOT Flash area ==<br />
<br />
This area will be used to locate Bootloader code. Not provided in this version<br />
<br />
= APPLICATION Flash area =<br />
<br />
Application Flash area hosts user application, drivers and Erika OS.<br />
<br />
== Erika OS ==<br />
<br />
Erika has been provide with the following configurations:<br />
<br />
* '''Single Core (DPM mode)'''. The main feaure of this configuration is that the user has 128 Kbytes of SRAM memory available divided in two memory banks (0x40000000 - 0x4000FFFF and 0x50000000 - 0x5000FFFF). This configuration can be executed from SRAM and from FLASH. The flags used to enable SRAM configurations is: __E200ZX_EXECUTE_FROM_RAM__, if it is not used, FLASH configuration is enabled by default. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:sram_dpm.png]]<br />
<br />
<br />
* '''Single core (Lock-step)'''. The main feaure of this configuration is that the user has 128 Kbytes of SRAM memory available (0x40000000 - 0x0001FFFF). This configuration can be executed from SRAM and from FLASH. In order to enable Lock-step mode the LOCK_STEP flag has to be enabled. This flag has to be combined with __E200ZX_EXECUTE_FROM_RAM__ if the target has to execute from SRAM. If only LOCK_STEP is enabled the target executes from Flash. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:sram_lock.png]]<br />
<br />
<br />
* '''Multicore (DPM mode)'''. The main feature of this configuration is that the user has 64 Kbytes of SRAM memory available for each core. In particular the first 64 Kbytes-bank of SRAM memory (0x40000000 - 0x4000FFFF) is allocated to the master core, this memory area also hosts data shared by both cores. The second 64 Kbytes-bank of SRAM memory (0x50000000 - 0x5000FFFF) is allocated to the slave core. In order to enable this configuration the flag __MSRP__ has to be defined. It has to be combined with __E200ZX_EXECUTE_FROM_RAM__ to have a system running from SRAM. If this flag is not enabled, hence the multicore application is configured to run from Flash. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:multi_dpm.png]]<br />
<br />
<br />
'''Additional notes about Erika-multicore in MPC5643L'''<br />
<br />
Erika uses hardware semaphores to guarantee data coherence between master and slave cores. It also used a signalling system based on software interrupts to provides basic inter-core synchronisation mechanism. MPC5643L has two SEMA4 modules, each module has 16 HW semaphores, but these semaphores are not all available by the user since they are used by the operating system to implement a barrier to synchronise both cores after boot sequence. According with these assumptions the 7-th software interrupt is used by signal mechanism and semaphore 0 and 1 of the master's SEMA4 module are used to implement synchronisation barrier, therefore they cannot be used for different purposes. All the remaining semaphores (from 2 to 15 belonging to the master's SEMA4 and all 16 belonging to the slave's SEMA4) and software interrupts (from 1 to 7 of both interrupt controllers) can be used by the user application. Notice that these limitations have to be taken into account only when the system is configured as multi-core. In single-core mode the user is free to use all software interrupts according with his needs, since boot-barrier is not enabled and inter-processor (software) interrupt are not required.<br />
<br />
== Drivers ==<br />
<br />
The implemented drivers are: CanDrv, FlashDrv, SpiDrv, Adc, Pwm and CTU. The details concerning these Drivers are reported in section Device Drivers.<br />
<br />
== User Application ==<br />
<br />
Evidence is not in charge of this part.<br />
<br />
= Board Internal Connections =<br />
<br />
This chapter provides a schema to show connections required for SPI, ADC, CAN (configured as CANDRV_NORMAL), System clock and one PWM signal (PWM0_A1).<br />
<br />
[[Image:board.png]]<br />
<br />
= Device Drivers =<br />
<br />
== Can Driver (CanDrv) ==<br />
<br />
Can Driver is based on Freescale FlexCan present in MPC5643L. Can Driver details will be provided in two distinct sections: configuration and API. Configuration section concerns Can Driver static configuration, that means that Can Driver has to be statically configured by CanCfg module (reference: sources/ApplCfg/CanCfg.c). The API section of the manual shows the set of functionalities featuring this CanDrv implemenation.<br />
<br />
=== CanDrv Configuration ===<br />
<br />
There two levels of CanDrv configuration: FlexCan level and message level. First level is used to configure Can Module with respect the following fields:<br />
<br />
* peripheralEn: it can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that the user wants to enabled or disabled the current Flexcan module. Notice that MPC5643L has two FlexCan modules.<br />
* mode: it can be CANDRV_NORMAL, CANDRV_LOOPBACK or CANDRV_OPENDRAIN. CANDRV_LOOPBACK means that FlexCan module works in loopback mode (look at Reference Manual for details. Ref: MPC5643LRM Rev. 9 12 Mar 2012), CANDRV_OPENDRAIN means that Flexcan is in open drain mode that means that user can connect two FlexCan modules available in MPC564L without the need of external connections.<br />
* autobusonEn: this field can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that the Auto-buson feature is enabled or not (look at Reference Manual for details. Ref: MPC5643LRM Rev. 9 12 Mar 2012)<br />
* peripheralFreq: this field determines FlexCan frequency. There five available values: CANDRV_1MBPS, CANDRV_500KBPS, CANDRV_250KBPS or CANDRV_125KBPS.<br />
* errorHandlingEn: it can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that user needs error handling capability.<br />
* sampleNumMode: it can be CANDRV_THREE_SAMPLE if user wants to sample the signal three times.<br />
<br />
In CW project and Integration project there are three cases (NORMAL, LOOPBACK and OPENDRAIN) characterised by their configuration parameters. LOOPBACK and OPENDRAIN cases are commented, in order to try these configurations please comment NORMAL mode and uncomment LOOPBACK or OPENDRAIN.<br />
The configuration version currently available in the repository provides FlexCan0 module enabled and FlexCan1 module disabled. All the fields of FlexCan1 are set to CANDRV_DO_NOT_CARE because peripheralEn is set to CANDRV_DISABLED. CanFlex0 is set as a 500 Kbps FlexCan module, with error handling enabled, auto-buson enabled, normal mode and three samples feature enabled.<br />
<br />
=== CanDrv API ===<br />
<br />
'''StdReturnType CanDrvInit(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Initialise canDrv component according with the features set in CanCfg module.<br />
<br />
'''void ManageCanIsr(uint8 isrSourceIndex, uint32 bufferFlags, CanChannelType canChannel);'''<br />
<br />
Input parameters are:<br />
* isrSourceIndex: is the offset in the FLAG1 register representing the isr source;<br />
* bufferFlags: the real isr source;<br />
* canChannel: represents FlexCan0 or FlexCan1<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Initialises Flexcan modules according with the user features set in CanCfg.<br />
<br />
'''StdReturnType CanTransmit(CanTxMsgIndexType msgIndex);'''<br />
<br />
Input parameters are:<br />
* msgIndex: message index taken from all message indexes defined by the user;<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
This function transmits "msgIndex" Can message. Return value of this function is the return value of CanSendManageMsg().<br />
<br />
'''StdReturnType CanPollMessage(CanRxMsgIndexType msgIndex, CanChannelType canChannel);'''<br />
<br />
Input parameters are:<br />
* msgIndex: message index taken from all message indexes defined by the user;<br />
* canChannel: FlexCan channel. It can be Flexcan0 or FlexCan1.<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
If canChannel is different fromFlexcan0 or Flexcan1, return value is STD_NOT_OK. If CanPollMessage() is called for a message for which a isr has been defined and the driver is working in INTERRUPT mode, return value is STD_NOT_OK. For all the remaining scenarios the return value is STD_OK.<br />
<br />
'''void CanDrvEnableInterrupts(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Enable Flexcan interrupts according with the CanCfg flags.<br />
<br />
'''void CanDrvDisableInterrupts(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Disable ALL FlexCan interrupts featuring ENABLED Flexcan modules.<br />
<br />
'''void CanDrvPolling(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function polls all FlexCan messages.<br />
<br />
== Spi Driver (SpiDrv) ==<br />
<br />
A simplified Spi Driver has been provide. Through this driver it is possible to use Spi Module both in Polling mode and Isr mode. APIs are defined as follow:<br />
<br />
'''void SpiTransmit(uint8 channel, uint8 chip_select, uint8 * data, uint8 length);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
* chip_select: is the cuip select (from 0 to 7).<br />
* length: is message length<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function transmits a spi message. Notice that no checks are performed on input parameters.<br />
<br />
'''StdReturnType SpiDrvInit(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
This function initialises Spi Driver according with flags present in SpiCfg module.<br />
<br />
'''void SpiPoolChannel(const uint8 channel, uint16_t * res);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
* res: is the location of the result<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function pools one Spi channel and store the result in the location pointed by res.<br />
<br />
'''uint32 SpiGetMessageLenght(const uint8 channel);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
<br />
Output parameter:<br />
* message length<br />
<br />
Description:<br />
<br />
Not still developed (NO REQUIREMENTS).<br />
<br />
== Pwm+Adc Drivers (with CTU support) ==<br />
<br />
In PWM driven systems it is important to schedule the acquisition of the state variables with respect to<br />
PWM cycle. State variables are obtained through the following peripherals: ADC, position counter (e.g.<br />
quadrature decoder, resolver and sine-cos sensor) and PWM duty cycle decoder.<br />
The cross triggering unit (CTU) is intended to completely avoid CPU involvement in the time acquisitions<br />
of state variables during the control cycle that can be the PWM cycle, the half PWM cycle or a number of<br />
PWM cycles. In such case the pre-setting of the acquisition times needs to be completed during the<br />
previous control cycle, where the actual acquisitions are to be made, and a double-buffered structure for<br />
the CTU registers is used, in order to activate the new settings at the beginning of the next control cycle.<br />
<br />
'''Problem:''' the main problem featuring this part of the application concerns ADC timing. In order to speed the acquisition up, the<br />
PWM A0 rising edge is used to trigger the Star-Of-Conversion (SOC). This means that whenever the PWM counter ramp reaches the maximum value,<br />
the CTU triggers a ADC acquisition without CPU intervention. This CTU action starts an ADC conversion at the beginning of 50 usec interval (SOC).<br />
Once the ADC conversion terminates at the End-Of-Conversion point (EOC at point 2), a ISR may be raised (but it has been disabled, since a polling strategy has<br />
been preferred). The remaining chunk of time (from EOC to the end of 50 usec), can be used for secondary activities (it is denoted as Free Bandwidth).<br />
At the end of 50-usecs interval, CTU triggers a new acquisition. Notice that the end of 50 usec represents a HARD Deadline, hence it will never being missed.<br />
<br />
[[Image:ctu.png]]<br />
<br />
'''Performance note:''' through a preliminary test, the interval of time between SOC and EOC (the red chunk) assumes a value equal to 790 PWM counter ticks (approximately 14 usec with a 120 Mhz CPU clock).<br />
<br />
=== PWM ===<br />
<br />
MPC5643L has two PWM modules, <br />
A simplified PWM Driver has been provide. Through this driver it is possible to access PWM basic functionalities. MPC5643L has two PWM modules, each PWM module has four PWM devices, for this application only a subset of FlexPWM0 module is used to generate three PWM signals: PWM0_A0, PWM0_A1 and PWM0_A2. APIs are defined as follow:<br />
<br />
'''void InitFlexPWM0(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function initialises FlexPWM0.<br />
<br />
'''void PWM0_AX_load_new_rising_edge(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: match value of the rising edge of X sub-module (X=0,1,2)<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function sets the match value (for rising edge) of PWM0_AX sub-module (X=0,1,2).<br />
<br />
'''void PWM0_AX_load_new_falling_edge(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: match value of the falling edge of X sub-module (X=0,1,2)<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function sets the match value (for falling edge) of PWM0_AX sub-module (X=0,1,2).<br />
<br />
=== ADC ===<br />
<br />
The Analog to Digital Converter (ADC) is a 12 bit Successive Approximation register (SAR) ADC with a mixed capacitive/resistive DAC. This device includes two ADC modules, referred to as ADC_0 and ADC_1. A conversion can be triggered by<br />
software or hardware (CTU), the solution selected for this application is the second one, that is based on CTU support. Currently the system starts the acquisition of 8 different ADC signals of the ADC_0 module as soon as CTU triggers the ADC_0 module. This happens whenever the internal counter of the PWM0 module matches its maximum value.<br />
<br />
External ADC channels:<br />
* 9 external channels on ADC_0 (channels 0..8)<br />
* 9 external channels on ADC_1 (channels 0..8)<br />
* 4 external channels shared between ADC_0 and ADC_1 (channels 11..14)<br />
<br />
This the list of ADC Driver APIs:<br />
<br />
'''StdReturnType InitADC(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
This function initialises ADC_0 module according with flags present in sources/ApplCfg/AdcCfg/AdcCfg.c. Data structure featuring ADC_0 and ADC_1 is adcConfContainer[2], it is characterised by the followinh data fields:<br />
<br />
* peripheralEn: it can be ADC_ENABLED/ADC_DISABLED to enable/disable ADC_0<br />
* peripheralFreq: it can be ADC_HALF_SYS_FREQ for a working freq. equal to 1/2 of the system freq. It can be ADC_SYS_FREQ if the user requires a working freq. equal to the system freq.<br />
* adcCommandConfigPtr: pointer to a CTU command list.<br />
<br />
<br />
'''uint8 AdcPollChannel(const uint8 adcModule, const uint8 channel)'''<br />
<br />
Input parameters are:<br />
* adcModule: it can be ADC__0 or ADC__1<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function pools the couple "ADC module and channel" represented by adcModule and channel.<br />
<br />
=== CTU (Cross Triggering Unit) ===<br />
<br />
The CTU in this context is used to synchronises the Star-Of-Conversion of the ADC0 channel to the PWM0 counter rising edge , this has been guaranteed without any CPU intervention. CTU has to be initialised in order to accomplish this requirement. All the initialization parameters are collected in one API:<br />
<br />
'''void InitCTU(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function initialises CTU to address the problem shown at the beginning of section "Pwm+Adc Drivers (with CTU support)".<br />
<br />
== Stm Driver ==<br />
<br />
Driver supporting basic STM (System Timer Module) functionalities. In the Erika repository is also provided a AUTOSAR-like version of STM Driver. This is the list of APIs featuring this STM basic driver:<br />
<br />
'''void mpc5643l_stm_freeze_on(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Enable freeze mode option of STM timer. If enabled, when system switches to debug mode, timer stops running.<br />
<br />
'''void mpc5643l_stm_freeze_off(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Disable freeze mode option of STM timer. If disabled, when system switches to debug mode, timer continues to increment.<br />
<br />
'''void mpc5643l_stm_set_prescaler(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: prescaler value<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function set STM prescaler<br />
<br />
'''void mpc5643l_stm_select_channel(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be use<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function select STM timer to use<br />
<br />
'''void mpc5643l_stm_unselect_channel(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function deselects a specific STM channel.<br />
<br />
'''void mpc5643l_stm_channel_cmp(unsigned int ch, unsigned int val);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
* val: comparator value<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This set a comparator for a specific STM channel<br />
<br />
'''void mpc5643l_stm_clear_int(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Clear interrupt for a specific STM channel<br />
<br />
'''void mpc5643l_stm_set_counter(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: set the counter of the STM<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Set STM counter value<br />
<br />
'''void mpc5643l_stm_enable(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Enable STM<br />
<br />
'''void mpc5643l_stm_disable(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Disable STM<br />
<br />
= Lauterbach Support =<br />
<br />
The reference debugging solution for MPC5643L is Lauterbach. In the Erika tree (look at pkg/mcu/freescale_mpc5643l/cfg) is collected a set of Lauterbach sripts for single and multicore configurations. Such a scripts also provide support for execution from SRAM and Flash, in VLE and BookE mode. MPC5643L provides the capability to work in lock-step mode, for this reason a script to pass from/to DPM/lock-step mode is provide (set_lsm_dpm.cmm). To launch this script, user have to launch Lauterbach Tracer first (for instance by editing "t32mppc" in Linux prompt, or equivalent command under Window), and then editing "do set_lsm_dpm.cmm" in the Lauterbach command prompt. This script provides several functionalities, but the only functionality addressed by this manual is the one to switch from/to lock-step/DPM mode. Once the user launches this script the following window appears:<br />
<br />
<br />
[[Image:set_lock_step.png]]<br />
<br />
<br />
Red box shows two buttons to select lock-step or DPM mode. For instance, in this case we have a system set as DPM, if we would like to switch to LSM mode, we have to press the LSM button, and then press "PROGRAM". After this action, a confirmation window will be shown, press "YES" to confirm:<br />
<br />
<br />
[[Image:lock_step_ok_button.png]]<br />
<br />
<br />
If the programming task is successfully accomplished, the following window will be shown. Press "OK" to terminate the script.<br />
<br />
<br />
[[Image:lock_step_ok_message.png]]<br />
<br />
<br />
<span style="color:#ff0000"> IMPORTANT NOTE: </span> in order to make the switch-mode effective, a power-cycle has to be done. Therefore power your board off, and then power it on.</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=File:Lock_step_ok_message.pngFile:Lock step ok message.png2014-11-10T13:42:53Z<p>Francesco: </p>
<hr />
<div></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=File:Lock_step_ok_button.pngFile:Lock step ok button.png2014-11-10T13:42:36Z<p>Francesco: </p>
<hr />
<div></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=File:Set_lock_step.pngFile:Set lock step.png2014-11-10T13:42:14Z<p>Francesco: </p>
<hr />
<div></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=File:Ctu.pngFile:Ctu.png2014-11-10T13:41:10Z<p>Francesco: </p>
<hr />
<div></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=File:Board.pngFile:Board.png2014-11-10T13:40:16Z<p>Francesco: </p>
<hr />
<div></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=File:Multi_dpm.pngFile:Multi dpm.png2014-11-10T13:39:21Z<p>Francesco: </p>
<hr />
<div></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=File:Sram_lock.pngFile:Sram lock.png2014-11-10T13:38:59Z<p>Francesco: </p>
<hr />
<div></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=File:Sram_dpm.pngFile:Sram dpm.png2014-11-10T13:38:38Z<p>Francesco: </p>
<hr />
<div></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=File:Flash_map_prova.pngFile:Flash map prova.png2014-11-10T13:37:16Z<p>Francesco: </p>
<hr />
<div></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=ERIKA_Enterprise_Device_Drivers_for_Leopard_MPC5643LERIKA Enterprise Device Drivers for Leopard MPC5643L2014-11-10T13:36:55Z<p>Francesco: /* Flash Usage */</p>
<hr />
<div>= Backlog =<br />
<br />
Il backlog e' su google docs su [https://docs.google.com/spreadsheet/ccc?key=0AsS2INzQeayzdG1yNUVTWUVMSHFtcVJ6ejJnVnh2eHc questo link] --- NO LONGER IN USE ---<br />
<br />
= Architecture description (Ref. MPC5643LRM Rev. 9 12 Mar 2012) =<br />
<br />
The Qorivva MPC5643L microcontroller is based on the Power Architecture. All MPC5643L devices are built around a dual-core safety platform, each core is a member of the e200z4 Power Architecture family. Lock step Redundancy Checking Units are implemented at each output of this Sphere of Replication (SoR). ECC is available for on-chip SRAM and flash memories. A programmable fault collection and control unit monitors the integrity status of the device and provides flexible safe state control. The peripheral set provides high-end electrical motor control capability with very low CPU intervention due to the on-chip cross-triggering unit (CTU).<br />
<br />
= Flash Usage =<br />
<br />
There are three address spaces featuring Flash memory of MPC5643L:<br />
<br />
* Low address space (256 KB)<br />
* Mid address space (256 KB)<br />
* High address space (512 KB)<br />
<br />
The MPC5643L flash memory usage has been managed as follow.<br />
<br />
* Block L0 (0x0 - 0x00004000) hosts the boot key of the microcontroler. MPC5643L has several boot sectors, Each boot sector in the flash memory contains at offset 0x00 the Reset Configuration Half-Word (RCHW) that is composed by 2 parts. First part is used to mark this boot sector as "bootable" (0x5A), second part to set VLE/BOOK E mode:<br />
<br />
# 0x15a0000 if the microcontroller runs in "VLE" mode<br />
# 0x05a0000 if the microcontroller runs in "BOOK E" mode<br />
<br />
RCHW is immediately followed by the reset vector of the microcontroller (the address from the microncontroller starts from).<br />
<br />
* Block L1, L2 and L3 (0x00004000 - 0x00020000) hosts Non-Volatile-RAM (NVRAM) data. The policy in charge of managing this flash area is explained in section NVRAM.<br />
* Block L4 and L5 (0x00020000 - 0x00040000) hosts boot code. The content of this flash area is explained in section BOOT.<br />
* Block M0 and M1 (0x00040000 - 0x00080000) hosts calibrations data. The policy in charge of managing this flash area is explained in section CALIBRATIONS.<br />
* Block H0 and H1 (0x00080000 - 0x000C0000) hosts application code. The content of this flash area is explained in section APPLICATION.<br />
<br />
Flash memory is devised as follow:<br />
<br />
[[Image:Flash_map_prova.png]]<br />
<br />
== BOOT Flash area ==<br />
<br />
This area will be used to locate Bootloader code. Not provided in this version<br />
<br />
= APPLICATION Flash area =<br />
<br />
Application Flash area hosts user application, drivers and Erika OS.<br />
<br />
== Erika OS ==<br />
<br />
Erika has been provide with the following configurations:<br />
<br />
* '''Single Core (DPM mode)'''. The main feaure of this configuration is that the user has 128 Kbytes of SRAM memory available divided in two memory banks (0x40000000 - 0x4000FFFF and 0x50000000 - 0x5000FFFF). This configuration can be executed from SRAM and from FLASH. The flags used to enable SRAM configurations is: __E200ZX_EXECUTE_FROM_RAM__, if it is not used, FLASH configuration is enabled by default. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:sram_dpm.png]]<br />
<br />
<br />
* '''Single core (Lock-step)'''. The main feaure of this configuration is that the user has 128 Kbytes of SRAM memory available (0x40000000 - 0x0001FFFF). This configuration can be executed from SRAM and from FLASH. In order to enable Lock-step mode the LOCK_STEP flag has to be enabled. This flag has to be combined with __E200ZX_EXECUTE_FROM_RAM__ if the target has to execute from SRAM. If only LOCK_STEP is enabled the target executes from Flash. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:sram_lock.png]]<br />
<br />
<br />
* '''Multicore (DPM mode)'''. The main feature of this configuration is that the user has 64 Kbytes of SRAM memory available for each core. In particular the first 64 Kbytes-bank of SRAM memory (0x40000000 - 0x4000FFFF) is allocated to the master core, this memory area also hosts data shared by both cores. The second 64 Kbytes-bank of SRAM memory (0x50000000 - 0x5000FFFF) is allocated to the slave core. In order to enable this configuration the flag __MSRP__ has to be defined. It has to be combined with __E200ZX_EXECUTE_FROM_RAM__ to have a system running from SRAM. If this flag is not enabled, hence the multicore application is configured to run from Flash. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:multi_dpm.png]]<br />
<br />
<br />
'''Additional notes about Erika-multicore in MPC5643L'''<br />
<br />
Erika uses hardware semaphores to guarantee data coherence between master and slave cores. It also used a signalling system based on software interrupts to provides basic inter-core synchronisation mechanism. MPC5643L has two SEMA4 modules, each module has 16 HW semaphores, but these semaphores are not all available by the user since they are used by the operating system to implement a barrier to synchronise both cores after boot sequence. According with these assumptions the 7-th software interrupt is used by signal mechanism and semaphore 0 and 1 of the master's SEMA4 module are used to implement synchronisation barrier, therefore they cannot be used for different purposes. All the remaining semaphores (from 2 to 15 belonging to the master's SEMA4 and all 16 belonging to the slave's SEMA4) and software interrupts (from 1 to 7 of both interrupt controllers) can be used by the user application. Notice that these limitations have to be taken into account only when the system is configured as multi-core. In single-core mode the user is free to use all software interrupts according with his needs, since boot-barrier is not enabled and inter-processor (software) interrupt are not required.<br />
<br />
== Drivers ==<br />
<br />
The implemented drivers are: CanDrv, FlashDrv, SpiDrv, Adc, Pwm and CTU. The details concerning these Drivers are reported in section Device Drivers.<br />
<br />
== User Application ==<br />
<br />
Evidence is not in charge of this part.<br />
<br />
= Board Internal Connections =<br />
<br />
This chapter provides a schema to show connections required for SPI, ADC, CAN (configured as CANDRV_NORMAL), System clock and one PWM signal (PWM0_A1).<br />
<br />
[[Image:board.png]]<br />
<br />
= Device Drivers =<br />
<br />
== Can Driver (CanDrv) ==<br />
<br />
Can Driver is based on Freescale FlexCan present in MPC5643L. Can Driver details will be provided in two distinct sections: configuration and API. Configuration section concerns Can Driver static configuration, that means that Can Driver has to be statically configured by CanCfg module (reference: sources/ApplCfg/CanCfg.c). The API section of the manual shows the set of functionalities featuring this CanDrv implemenation.<br />
<br />
=== CanDrv Configuration ===<br />
<br />
There two levels of CanDrv configuration: FlexCan level and message level. First level is used to configure Can Module with respect the following fields:<br />
<br />
* peripheralEn: it can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that the user wants to enabled or disabled the current Flexcan module. Notice that MPC5643L has two FlexCan modules.<br />
* mode: it can be CANDRV_NORMAL, CANDRV_LOOPBACK or CANDRV_OPENDRAIN. CANDRV_LOOPBACK means that FlexCan module works in loopback mode (look at Reference Manual for details. Ref: MPC5643LRM Rev. 9 12 Mar 2012), CANDRV_OPENDRAIN means that Flexcan is in open drain mode that means that user can connect two FlexCan modules available in MPC564L without the need of external connections.<br />
* autobusonEn: this field can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that the Auto-buson feature is enabled or not (look at Reference Manual for details. Ref: MPC5643LRM Rev. 9 12 Mar 2012)<br />
* peripheralFreq: this field determines FlexCan frequency. There five available values: CANDRV_1MBPS, CANDRV_500KBPS, CANDRV_250KBPS or CANDRV_125KBPS.<br />
* errorHandlingEn: it can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that user needs error handling capability.<br />
* sampleNumMode: it can be CANDRV_THREE_SAMPLE if user wants to sample the signal three times.<br />
<br />
In CW project and Integration project there are three cases (NORMAL, LOOPBACK and OPENDRAIN) characterised by their configuration parameters. LOOPBACK and OPENDRAIN cases are commented, in order to try these configurations please comment NORMAL mode and uncomment LOOPBACK or OPENDRAIN.<br />
The configuration version currently available in the repository provides FlexCan0 module enabled and FlexCan1 module disabled. All the fields of FlexCan1 are set to CANDRV_DO_NOT_CARE because peripheralEn is set to CANDRV_DISABLED. CanFlex0 is set as a 500 Kbps FlexCan module, with error handling enabled, auto-buson enabled, normal mode and three samples feature enabled.<br />
<br />
=== CanDrv API ===<br />
<br />
'''StdReturnType CanDrvInit(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Initialise canDrv component according with the features set in CanCfg module.<br />
<br />
'''void ManageCanIsr(uint8 isrSourceIndex, uint32 bufferFlags, CanChannelType canChannel);'''<br />
<br />
Input parameters are:<br />
* isrSourceIndex: is the offset in the FLAG1 register representing the isr source;<br />
* bufferFlags: the real isr source;<br />
* canChannel: represents FlexCan0 or FlexCan1<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Initialises Flexcan modules according with the user features set in CanCfg.<br />
<br />
'''StdReturnType CanTransmit(CanTxMsgIndexType msgIndex);'''<br />
<br />
Input parameters are:<br />
* msgIndex: message index taken from all message indexes defined by the user;<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
This function transmits "msgIndex" Can message. Return value of this function is the return value of CanSendManageMsg().<br />
<br />
'''StdReturnType CanPollMessage(CanRxMsgIndexType msgIndex, CanChannelType canChannel);'''<br />
<br />
Input parameters are:<br />
* msgIndex: message index taken from all message indexes defined by the user;<br />
* canChannel: FlexCan channel. It can be Flexcan0 or FlexCan1.<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
If canChannel is different fromFlexcan0 or Flexcan1, return value is STD_NOT_OK. If CanPollMessage() is called for a message for which a isr has been defined and the driver is working in INTERRUPT mode, return value is STD_NOT_OK. For all the remaining scenarios the return value is STD_OK.<br />
<br />
'''void CanDrvEnableInterrupts(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Enable Flexcan interrupts according with the CanCfg flags.<br />
<br />
'''void CanDrvDisableInterrupts(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Disable ALL FlexCan interrupts featuring ENABLED Flexcan modules.<br />
<br />
'''void CanDrvPolling(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function polls all FlexCan messages.<br />
<br />
== Spi Driver (SpiDrv) ==<br />
<br />
A simplified Spi Driver has been provide. Through this driver it is possible to use Spi Module both in Polling mode and Isr mode. APIs are defined as follow:<br />
<br />
'''void SpiTransmit(uint8 channel, uint8 chip_select, uint8 * data, uint8 length);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
* chip_select: is the cuip select (from 0 to 7).<br />
* length: is message length<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function transmits a spi message. Notice that no checks are performed on input parameters.<br />
<br />
'''StdReturnType SpiDrvInit(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
This function initialises Spi Driver according with flags present in SpiCfg module.<br />
<br />
'''void SpiPoolChannel(const uint8 channel, uint16_t * res);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
* res: is the location of the result<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function pools one Spi channel and store the result in the location pointed by res.<br />
<br />
'''uint32 SpiGetMessageLenght(const uint8 channel);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
<br />
Output parameter:<br />
* message length<br />
<br />
Description:<br />
<br />
Not still developed (NO REQUIREMENTS).<br />
<br />
== Pwm+Adc Drivers (with CTU support) ==<br />
<br />
In PWM driven systems it is important to schedule the acquisition of the state variables with respect to<br />
PWM cycle. State variables are obtained through the following peripherals: ADC, position counter (e.g.<br />
quadrature decoder, resolver and sine-cos sensor) and PWM duty cycle decoder.<br />
The cross triggering unit (CTU) is intended to completely avoid CPU involvement in the time acquisitions<br />
of state variables during the control cycle that can be the PWM cycle, the half PWM cycle or a number of<br />
PWM cycles. In such case the pre-setting of the acquisition times needs to be completed during the<br />
previous control cycle, where the actual acquisitions are to be made, and a double-buffered structure for<br />
the CTU registers is used, in order to activate the new settings at the beginning of the next control cycle.<br />
<br />
'''Problem:''' the main problem featuring this part of the application concerns ADC timing. In order to speed the acquisition up, the<br />
PWM A0 rising edge is used to trigger the Star-Of-Conversion (SOC). This means that whenever the PWM counter ramp reaches the maximum value,<br />
the CTU triggers a ADC acquisition without CPU intervention. This CTU action starts an ADC conversion at the beginning of 50 usec interval (SOC).<br />
Once the ADC conversion terminates at the End-Of-Conversion point (EOC at point 2), a ISR may be raised (but it has been disabled, since a polling strategy has<br />
been preferred). The remaining chunk of time (from EOC to the end of 50 usec), can be used for secondary activities (it is denoted as Free Bandwidth).<br />
At the end of 50-usecs interval, CTU triggers a new acquisition. Notice that the end of 50 usec represents a HARD Deadline, hence it will never being missed.<br />
<br />
[[Image:ctu.png]]<br />
<br />
'''Performance note:''' through a preliminary test, the interval of time between SOC and EOC (the red chunk) assumes a value equal to 790 PWM counter ticks (approximately 14 usec with a 120 Mhz CPU clock).<br />
<br />
=== PWM ===<br />
<br />
MPC5643L has two PWM modules, <br />
A simplified PWM Driver has been provide. Through this driver it is possible to access PWM basic functionalities. MPC5643L has two PWM modules, each PWM module has four PWM devices, for this application only a subset of FlexPWM0 module is used to generate three PWM signals: PWM0_A0, PWM0_A1 and PWM0_A2. APIs are defined as follow:<br />
<br />
'''void InitFlexPWM0(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function initialises FlexPWM0.<br />
<br />
'''void PWM0_AX_load_new_rising_edge(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: match value of the rising edge of X sub-module (X=0,1,2)<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function sets the match value (for rising edge) of PWM0_AX sub-module (X=0,1,2).<br />
<br />
'''void PWM0_AX_load_new_falling_edge(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: match value of the falling edge of X sub-module (X=0,1,2)<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function sets the match value (for falling edge) of PWM0_AX sub-module (X=0,1,2).<br />
<br />
=== ADC ===<br />
<br />
The Analog to Digital Converter (ADC) is a 12 bit Successive Approximation register (SAR) ADC with a mixed capacitive/resistive DAC. This device includes two ADC modules, referred to as ADC_0 and ADC_1. A conversion can be triggered by<br />
software or hardware (CTU), the solution selected for this application is the second one, that is based on CTU support. Currently the system starts the acquisition of 8 different ADC signals of the ADC_0 module as soon as CTU triggers the ADC_0 module. This happens whenever the internal counter of the PWM0 module matches its maximum value.<br />
<br />
External ADC channels:<br />
* 9 external channels on ADC_0 (channels 0..8)<br />
* 9 external channels on ADC_1 (channels 0..8)<br />
* 4 external channels shared between ADC_0 and ADC_1 (channels 11..14)<br />
<br />
This the list of ADC Driver APIs:<br />
<br />
'''StdReturnType InitADC(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
This function initialises ADC_0 module according with flags present in sources/ApplCfg/AdcCfg/AdcCfg.c. Data structure featuring ADC_0 and ADC_1 is adcConfContainer[2], it is characterised by the followinh data fields:<br />
<br />
* peripheralEn: it can be ADC_ENABLED/ADC_DISABLED to enable/disable ADC_0<br />
* peripheralFreq: it can be ADC_HALF_SYS_FREQ for a working freq. equal to 1/2 of the system freq. It can be ADC_SYS_FREQ if the user requires a working freq. equal to the system freq.<br />
* adcCommandConfigPtr: pointer to a CTU command list.<br />
<br />
<br />
'''uint8 AdcPollChannel(const uint8 adcModule, const uint8 channel)'''<br />
<br />
Input parameters are:<br />
* adcModule: it can be ADC__0 or ADC__1<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function pools the couple "ADC module and channel" represented by adcModule and channel.<br />
<br />
=== CTU (Cross Triggering Unit) ===<br />
<br />
The CTU in this context is used to synchronises the Star-Of-Conversion of the ADC0 channel to the PWM0 counter rising edge , this has been guaranteed without any CPU intervention. CTU has to be initialised in order to accomplish this requirement. All the initialization parameters are collected in one API:<br />
<br />
'''void InitCTU(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function initialises CTU to address the problem shown at the beginning of section "Pwm+Adc Drivers (with CTU support)".<br />
<br />
== Stm Driver ==<br />
<br />
Driver supporting basic STM (System Timer Module) functionalities. In the Erika repository is also provided a AUTOSAR-like version of STM Driver. This is the list of APIs featuring this STM basic driver:<br />
<br />
'''void mpc5643l_stm_freeze_on(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Enable freeze mode option of STM timer. If enabled, when system switches to debug mode, timer stops running.<br />
<br />
'''void mpc5643l_stm_freeze_off(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Disable freeze mode option of STM timer. If disabled, when system switches to debug mode, timer continues to increment.<br />
<br />
'''void mpc5643l_stm_set_prescaler(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: prescaler value<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function set STM prescaler<br />
<br />
'''void mpc5643l_stm_select_channel(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be use<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function select STM timer to use<br />
<br />
'''void mpc5643l_stm_unselect_channel(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function deselects a specific STM channel.<br />
<br />
'''void mpc5643l_stm_channel_cmp(unsigned int ch, unsigned int val);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
* val: comparator value<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This set a comparator for a specific STM channel<br />
<br />
'''void mpc5643l_stm_clear_int(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Clear interrupt for a specific STM channel<br />
<br />
'''void mpc5643l_stm_set_counter(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: set the counter of the STM<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Set STM counter value<br />
<br />
'''void mpc5643l_stm_enable(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Enable STM<br />
<br />
'''void mpc5643l_stm_disable(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Disable STM<br />
<br />
= Lauterbach Support =<br />
<br />
The reference debugging solution for MPC5643L is Lauterbach. In the Erika tree (look at pkg/mcu/freescale_mpc5643l/cfg) is collected a set of Lauterbach sripts for single and multicore configurations. Such a scripts also provide support for execution from SRAM and Flash, in VLE and BookE mode. MPC5643L provides the capability to work in lock-step mode, for this reason a script to pass from/to DPM/lock-step mode is provide (set_lsm_dpm.cmm). To launch this script, user have to launch Lauterbach Tracer first (for instance by editing "t32mppc" in Linux prompt, or equivalent command under Window), and then editing "do set_lsm_dpm.cmm" in the Lauterbach command prompt. This script provides several functionalities, but the only functionality addressed by this manual is the one to switch from/to lock-step/DPM mode. Once the user launches this script the following window appears:<br />
<br />
<br />
[[Image:set_lock_step.png]]<br />
<br />
<br />
Red box shows two buttons to select lock-step or DPM mode. For instance, in this case we have a system set as DPM, if we would like to switch to LSM mode, we have to press the LSM button, and then press "PROGRAM". After this action, a confirmation window will be shown, press "YES" to confirm:<br />
<br />
<br />
[[Image:lock_step_ok_button.png]]<br />
<br />
<br />
If the programming task is successfully accomplished, the following window will be shown. Press "OK" to terminate the script.<br />
<br />
<br />
[[Image:lock_step_ok_message.png]]<br />
<br />
<br />
<span style="color:#ff0000"> IMPORTANT NOTE: </span> in order to make the switch-mode effective, a power-cycle has to be done. Therefore power your board off, and then power it on.<br />
<br />
= Project structure =<br />
<br />
The project is structured in three branches: CW, integration and integration_multi. The remaining directories are not relevant. CW project is based on Codewarrior IDE and works both for Linux and for Windows, it also provides support for the basic debugging system of Freescale based on P&E debugger. The project named "integration_multi" is a draft project to be considered as an example of MPC5643L used in multicore configuration. It provides a simple multitasking application distributed among two cores and using inter-processor interrupts and HW semaphores. The "integration" project is the project used as base-line to build up Erika libraries, linker scripts, boot modules and OS configuration files. These files have to be copied to CW project in order to build up a fully system to be integrated in a Codewarrior IDE. A simple bash script is provide as example to perform this copy: copy.sh.</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=ERIKA_Enterprise_Device_Drivers_for_Leopard_MPC5643LERIKA Enterprise Device Drivers for Leopard MPC5643L2014-11-10T13:34:44Z<p>Francesco: /* Flash Usage */</p>
<hr />
<div>= Backlog =<br />
<br />
Il backlog e' su google docs su [https://docs.google.com/spreadsheet/ccc?key=0AsS2INzQeayzdG1yNUVTWUVMSHFtcVJ6ejJnVnh2eHc questo link] --- NO LONGER IN USE ---<br />
<br />
= Architecture description (Ref. MPC5643LRM Rev. 9 12 Mar 2012) =<br />
<br />
The Qorivva MPC5643L microcontroller is based on the Power Architecture. All MPC5643L devices are built around a dual-core safety platform, each core is a member of the e200z4 Power Architecture family. Lock step Redundancy Checking Units are implemented at each output of this Sphere of Replication (SoR). ECC is available for on-chip SRAM and flash memories. A programmable fault collection and control unit monitors the integrity status of the device and provides flexible safe state control. The peripheral set provides high-end electrical motor control capability with very low CPU intervention due to the on-chip cross-triggering unit (CTU).<br />
<br />
= Flash Usage =<br />
<br />
There are three address spaces featuring Flash memory of MPC5643L:<br />
<br />
* Low address space (256 KB)<br />
* Mid address space (256 KB)<br />
* High address space (512 KB)<br />
<br />
The MPC5643L flash memory usage has been managed as follow.<br />
<br />
* Block L0 (0x0 - 0x00004000) hosts the boot key of the microcontroler. MPC5643L has several boot sectors, Each boot sector in the flash memory contains at offset 0x00 the Reset Configuration Half-Word (RCHW) that is composed by 2 parts. First part is used to mark this boot sector as "bootable" (0x5A), second part to set VLE/BOOK E mode:<br />
<br />
# 0x15a0000 if the microcontroller runs in "VLE" mode<br />
# 0x05a0000 if the microcontroller runs in "BOOK E" mode<br />
<br />
RCHW is immediately followed by the reset vector of the microcontroller (the address from the microncontroller starts from).<br />
<br />
* Block L1, L2 and L3 (0x00004000 - 0x00020000) hosts Non-Volatile-RAM (NVRAM) data. The policy in charge of managing this flash area is explained in section NVRAM.<br />
* Block L4 and L5 (0x00020000 - 0x00040000) hosts boot code. The content of this flash area is explained in section BOOT.<br />
* Block M0 and M1 (0x00040000 - 0x00080000) hosts calibrations data. The policy in charge of managing this flash area is explained in section CALIBRATIONS.<br />
* Block H0 and H1 (0x00080000 - 0x000C0000) hosts application code. The content of this flash area is explained in section APPLICATION.<br />
<br />
Flash memory is devised as follow:<br />
<br />
[[http://wiki/index.php/Image:Flash_map_prova.png]]<br />
<br />
== BOOT Flash area ==<br />
<br />
This area will be used to locate Bootloader code. Not provided in this version<br />
<br />
= APPLICATION Flash area =<br />
<br />
Application Flash area hosts user application, drivers and Erika OS.<br />
<br />
== Erika OS ==<br />
<br />
Erika has been provide with the following configurations:<br />
<br />
* '''Single Core (DPM mode)'''. The main feaure of this configuration is that the user has 128 Kbytes of SRAM memory available divided in two memory banks (0x40000000 - 0x4000FFFF and 0x50000000 - 0x5000FFFF). This configuration can be executed from SRAM and from FLASH. The flags used to enable SRAM configurations is: __E200ZX_EXECUTE_FROM_RAM__, if it is not used, FLASH configuration is enabled by default. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:sram_dpm.png]]<br />
<br />
<br />
* '''Single core (Lock-step)'''. The main feaure of this configuration is that the user has 128 Kbytes of SRAM memory available (0x40000000 - 0x0001FFFF). This configuration can be executed from SRAM and from FLASH. In order to enable Lock-step mode the LOCK_STEP flag has to be enabled. This flag has to be combined with __E200ZX_EXECUTE_FROM_RAM__ if the target has to execute from SRAM. If only LOCK_STEP is enabled the target executes from Flash. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:sram_lock.png]]<br />
<br />
<br />
* '''Multicore (DPM mode)'''. The main feature of this configuration is that the user has 64 Kbytes of SRAM memory available for each core. In particular the first 64 Kbytes-bank of SRAM memory (0x40000000 - 0x4000FFFF) is allocated to the master core, this memory area also hosts data shared by both cores. The second 64 Kbytes-bank of SRAM memory (0x50000000 - 0x5000FFFF) is allocated to the slave core. In order to enable this configuration the flag __MSRP__ has to be defined. It has to be combined with __E200ZX_EXECUTE_FROM_RAM__ to have a system running from SRAM. If this flag is not enabled, hence the multicore application is configured to run from Flash. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:multi_dpm.png]]<br />
<br />
<br />
'''Additional notes about Erika-multicore in MPC5643L'''<br />
<br />
Erika uses hardware semaphores to guarantee data coherence between master and slave cores. It also used a signalling system based on software interrupts to provides basic inter-core synchronisation mechanism. MPC5643L has two SEMA4 modules, each module has 16 HW semaphores, but these semaphores are not all available by the user since they are used by the operating system to implement a barrier to synchronise both cores after boot sequence. According with these assumptions the 7-th software interrupt is used by signal mechanism and semaphore 0 and 1 of the master's SEMA4 module are used to implement synchronisation barrier, therefore they cannot be used for different purposes. All the remaining semaphores (from 2 to 15 belonging to the master's SEMA4 and all 16 belonging to the slave's SEMA4) and software interrupts (from 1 to 7 of both interrupt controllers) can be used by the user application. Notice that these limitations have to be taken into account only when the system is configured as multi-core. In single-core mode the user is free to use all software interrupts according with his needs, since boot-barrier is not enabled and inter-processor (software) interrupt are not required.<br />
<br />
== Drivers ==<br />
<br />
The implemented drivers are: CanDrv, FlashDrv, SpiDrv, Adc, Pwm and CTU. The details concerning these Drivers are reported in section Device Drivers.<br />
<br />
== User Application ==<br />
<br />
Evidence is not in charge of this part.<br />
<br />
= Board Internal Connections =<br />
<br />
This chapter provides a schema to show connections required for SPI, ADC, CAN (configured as CANDRV_NORMAL), System clock and one PWM signal (PWM0_A1).<br />
<br />
[[Image:board.png]]<br />
<br />
= Device Drivers =<br />
<br />
== Can Driver (CanDrv) ==<br />
<br />
Can Driver is based on Freescale FlexCan present in MPC5643L. Can Driver details will be provided in two distinct sections: configuration and API. Configuration section concerns Can Driver static configuration, that means that Can Driver has to be statically configured by CanCfg module (reference: sources/ApplCfg/CanCfg.c). The API section of the manual shows the set of functionalities featuring this CanDrv implemenation.<br />
<br />
=== CanDrv Configuration ===<br />
<br />
There two levels of CanDrv configuration: FlexCan level and message level. First level is used to configure Can Module with respect the following fields:<br />
<br />
* peripheralEn: it can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that the user wants to enabled or disabled the current Flexcan module. Notice that MPC5643L has two FlexCan modules.<br />
* mode: it can be CANDRV_NORMAL, CANDRV_LOOPBACK or CANDRV_OPENDRAIN. CANDRV_LOOPBACK means that FlexCan module works in loopback mode (look at Reference Manual for details. Ref: MPC5643LRM Rev. 9 12 Mar 2012), CANDRV_OPENDRAIN means that Flexcan is in open drain mode that means that user can connect two FlexCan modules available in MPC564L without the need of external connections.<br />
* autobusonEn: this field can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that the Auto-buson feature is enabled or not (look at Reference Manual for details. Ref: MPC5643LRM Rev. 9 12 Mar 2012)<br />
* peripheralFreq: this field determines FlexCan frequency. There five available values: CANDRV_1MBPS, CANDRV_500KBPS, CANDRV_250KBPS or CANDRV_125KBPS.<br />
* errorHandlingEn: it can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that user needs error handling capability.<br />
* sampleNumMode: it can be CANDRV_THREE_SAMPLE if user wants to sample the signal three times.<br />
<br />
In CW project and Integration project there are three cases (NORMAL, LOOPBACK and OPENDRAIN) characterised by their configuration parameters. LOOPBACK and OPENDRAIN cases are commented, in order to try these configurations please comment NORMAL mode and uncomment LOOPBACK or OPENDRAIN.<br />
The configuration version currently available in the repository provides FlexCan0 module enabled and FlexCan1 module disabled. All the fields of FlexCan1 are set to CANDRV_DO_NOT_CARE because peripheralEn is set to CANDRV_DISABLED. CanFlex0 is set as a 500 Kbps FlexCan module, with error handling enabled, auto-buson enabled, normal mode and three samples feature enabled.<br />
<br />
=== CanDrv API ===<br />
<br />
'''StdReturnType CanDrvInit(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Initialise canDrv component according with the features set in CanCfg module.<br />
<br />
'''void ManageCanIsr(uint8 isrSourceIndex, uint32 bufferFlags, CanChannelType canChannel);'''<br />
<br />
Input parameters are:<br />
* isrSourceIndex: is the offset in the FLAG1 register representing the isr source;<br />
* bufferFlags: the real isr source;<br />
* canChannel: represents FlexCan0 or FlexCan1<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Initialises Flexcan modules according with the user features set in CanCfg.<br />
<br />
'''StdReturnType CanTransmit(CanTxMsgIndexType msgIndex);'''<br />
<br />
Input parameters are:<br />
* msgIndex: message index taken from all message indexes defined by the user;<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
This function transmits "msgIndex" Can message. Return value of this function is the return value of CanSendManageMsg().<br />
<br />
'''StdReturnType CanPollMessage(CanRxMsgIndexType msgIndex, CanChannelType canChannel);'''<br />
<br />
Input parameters are:<br />
* msgIndex: message index taken from all message indexes defined by the user;<br />
* canChannel: FlexCan channel. It can be Flexcan0 or FlexCan1.<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
If canChannel is different fromFlexcan0 or Flexcan1, return value is STD_NOT_OK. If CanPollMessage() is called for a message for which a isr has been defined and the driver is working in INTERRUPT mode, return value is STD_NOT_OK. For all the remaining scenarios the return value is STD_OK.<br />
<br />
'''void CanDrvEnableInterrupts(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Enable Flexcan interrupts according with the CanCfg flags.<br />
<br />
'''void CanDrvDisableInterrupts(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Disable ALL FlexCan interrupts featuring ENABLED Flexcan modules.<br />
<br />
'''void CanDrvPolling(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function polls all FlexCan messages.<br />
<br />
== Spi Driver (SpiDrv) ==<br />
<br />
A simplified Spi Driver has been provide. Through this driver it is possible to use Spi Module both in Polling mode and Isr mode. APIs are defined as follow:<br />
<br />
'''void SpiTransmit(uint8 channel, uint8 chip_select, uint8 * data, uint8 length);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
* chip_select: is the cuip select (from 0 to 7).<br />
* length: is message length<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function transmits a spi message. Notice that no checks are performed on input parameters.<br />
<br />
'''StdReturnType SpiDrvInit(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
This function initialises Spi Driver according with flags present in SpiCfg module.<br />
<br />
'''void SpiPoolChannel(const uint8 channel, uint16_t * res);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
* res: is the location of the result<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function pools one Spi channel and store the result in the location pointed by res.<br />
<br />
'''uint32 SpiGetMessageLenght(const uint8 channel);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
<br />
Output parameter:<br />
* message length<br />
<br />
Description:<br />
<br />
Not still developed (NO REQUIREMENTS).<br />
<br />
== Pwm+Adc Drivers (with CTU support) ==<br />
<br />
In PWM driven systems it is important to schedule the acquisition of the state variables with respect to<br />
PWM cycle. State variables are obtained through the following peripherals: ADC, position counter (e.g.<br />
quadrature decoder, resolver and sine-cos sensor) and PWM duty cycle decoder.<br />
The cross triggering unit (CTU) is intended to completely avoid CPU involvement in the time acquisitions<br />
of state variables during the control cycle that can be the PWM cycle, the half PWM cycle or a number of<br />
PWM cycles. In such case the pre-setting of the acquisition times needs to be completed during the<br />
previous control cycle, where the actual acquisitions are to be made, and a double-buffered structure for<br />
the CTU registers is used, in order to activate the new settings at the beginning of the next control cycle.<br />
<br />
'''Problem:''' the main problem featuring this part of the application concerns ADC timing. In order to speed the acquisition up, the<br />
PWM A0 rising edge is used to trigger the Star-Of-Conversion (SOC). This means that whenever the PWM counter ramp reaches the maximum value,<br />
the CTU triggers a ADC acquisition without CPU intervention. This CTU action starts an ADC conversion at the beginning of 50 usec interval (SOC).<br />
Once the ADC conversion terminates at the End-Of-Conversion point (EOC at point 2), a ISR may be raised (but it has been disabled, since a polling strategy has<br />
been preferred). The remaining chunk of time (from EOC to the end of 50 usec), can be used for secondary activities (it is denoted as Free Bandwidth).<br />
At the end of 50-usecs interval, CTU triggers a new acquisition. Notice that the end of 50 usec represents a HARD Deadline, hence it will never being missed.<br />
<br />
[[Image:ctu.png]]<br />
<br />
'''Performance note:''' through a preliminary test, the interval of time between SOC and EOC (the red chunk) assumes a value equal to 790 PWM counter ticks (approximately 14 usec with a 120 Mhz CPU clock).<br />
<br />
=== PWM ===<br />
<br />
MPC5643L has two PWM modules, <br />
A simplified PWM Driver has been provide. Through this driver it is possible to access PWM basic functionalities. MPC5643L has two PWM modules, each PWM module has four PWM devices, for this application only a subset of FlexPWM0 module is used to generate three PWM signals: PWM0_A0, PWM0_A1 and PWM0_A2. APIs are defined as follow:<br />
<br />
'''void InitFlexPWM0(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function initialises FlexPWM0.<br />
<br />
'''void PWM0_AX_load_new_rising_edge(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: match value of the rising edge of X sub-module (X=0,1,2)<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function sets the match value (for rising edge) of PWM0_AX sub-module (X=0,1,2).<br />
<br />
'''void PWM0_AX_load_new_falling_edge(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: match value of the falling edge of X sub-module (X=0,1,2)<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function sets the match value (for falling edge) of PWM0_AX sub-module (X=0,1,2).<br />
<br />
=== ADC ===<br />
<br />
The Analog to Digital Converter (ADC) is a 12 bit Successive Approximation register (SAR) ADC with a mixed capacitive/resistive DAC. This device includes two ADC modules, referred to as ADC_0 and ADC_1. A conversion can be triggered by<br />
software or hardware (CTU), the solution selected for this application is the second one, that is based on CTU support. Currently the system starts the acquisition of 8 different ADC signals of the ADC_0 module as soon as CTU triggers the ADC_0 module. This happens whenever the internal counter of the PWM0 module matches its maximum value.<br />
<br />
External ADC channels:<br />
* 9 external channels on ADC_0 (channels 0..8)<br />
* 9 external channels on ADC_1 (channels 0..8)<br />
* 4 external channels shared between ADC_0 and ADC_1 (channels 11..14)<br />
<br />
This the list of ADC Driver APIs:<br />
<br />
'''StdReturnType InitADC(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
This function initialises ADC_0 module according with flags present in sources/ApplCfg/AdcCfg/AdcCfg.c. Data structure featuring ADC_0 and ADC_1 is adcConfContainer[2], it is characterised by the followinh data fields:<br />
<br />
* peripheralEn: it can be ADC_ENABLED/ADC_DISABLED to enable/disable ADC_0<br />
* peripheralFreq: it can be ADC_HALF_SYS_FREQ for a working freq. equal to 1/2 of the system freq. It can be ADC_SYS_FREQ if the user requires a working freq. equal to the system freq.<br />
* adcCommandConfigPtr: pointer to a CTU command list.<br />
<br />
<br />
'''uint8 AdcPollChannel(const uint8 adcModule, const uint8 channel)'''<br />
<br />
Input parameters are:<br />
* adcModule: it can be ADC__0 or ADC__1<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function pools the couple "ADC module and channel" represented by adcModule and channel.<br />
<br />
=== CTU (Cross Triggering Unit) ===<br />
<br />
The CTU in this context is used to synchronises the Star-Of-Conversion of the ADC0 channel to the PWM0 counter rising edge , this has been guaranteed without any CPU intervention. CTU has to be initialised in order to accomplish this requirement. All the initialization parameters are collected in one API:<br />
<br />
'''void InitCTU(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function initialises CTU to address the problem shown at the beginning of section "Pwm+Adc Drivers (with CTU support)".<br />
<br />
== Stm Driver ==<br />
<br />
Driver supporting basic STM (System Timer Module) functionalities. In the Erika repository is also provided a AUTOSAR-like version of STM Driver. This is the list of APIs featuring this STM basic driver:<br />
<br />
'''void mpc5643l_stm_freeze_on(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Enable freeze mode option of STM timer. If enabled, when system switches to debug mode, timer stops running.<br />
<br />
'''void mpc5643l_stm_freeze_off(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Disable freeze mode option of STM timer. If disabled, when system switches to debug mode, timer continues to increment.<br />
<br />
'''void mpc5643l_stm_set_prescaler(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: prescaler value<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function set STM prescaler<br />
<br />
'''void mpc5643l_stm_select_channel(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be use<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function select STM timer to use<br />
<br />
'''void mpc5643l_stm_unselect_channel(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function deselects a specific STM channel.<br />
<br />
'''void mpc5643l_stm_channel_cmp(unsigned int ch, unsigned int val);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
* val: comparator value<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This set a comparator for a specific STM channel<br />
<br />
'''void mpc5643l_stm_clear_int(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Clear interrupt for a specific STM channel<br />
<br />
'''void mpc5643l_stm_set_counter(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: set the counter of the STM<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Set STM counter value<br />
<br />
'''void mpc5643l_stm_enable(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Enable STM<br />
<br />
'''void mpc5643l_stm_disable(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Disable STM<br />
<br />
= Lauterbach Support =<br />
<br />
The reference debugging solution for MPC5643L is Lauterbach. In the Erika tree (look at pkg/mcu/freescale_mpc5643l/cfg) is collected a set of Lauterbach sripts for single and multicore configurations. Such a scripts also provide support for execution from SRAM and Flash, in VLE and BookE mode. MPC5643L provides the capability to work in lock-step mode, for this reason a script to pass from/to DPM/lock-step mode is provide (set_lsm_dpm.cmm). To launch this script, user have to launch Lauterbach Tracer first (for instance by editing "t32mppc" in Linux prompt, or equivalent command under Window), and then editing "do set_lsm_dpm.cmm" in the Lauterbach command prompt. This script provides several functionalities, but the only functionality addressed by this manual is the one to switch from/to lock-step/DPM mode. Once the user launches this script the following window appears:<br />
<br />
<br />
[[Image:set_lock_step.png]]<br />
<br />
<br />
Red box shows two buttons to select lock-step or DPM mode. For instance, in this case we have a system set as DPM, if we would like to switch to LSM mode, we have to press the LSM button, and then press "PROGRAM". After this action, a confirmation window will be shown, press "YES" to confirm:<br />
<br />
<br />
[[Image:lock_step_ok_button.png]]<br />
<br />
<br />
If the programming task is successfully accomplished, the following window will be shown. Press "OK" to terminate the script.<br />
<br />
<br />
[[Image:lock_step_ok_message.png]]<br />
<br />
<br />
<span style="color:#ff0000"> IMPORTANT NOTE: </span> in order to make the switch-mode effective, a power-cycle has to be done. Therefore power your board off, and then power it on.<br />
<br />
= Project structure =<br />
<br />
The project is structured in three branches: CW, integration and integration_multi. The remaining directories are not relevant. CW project is based on Codewarrior IDE and works both for Linux and for Windows, it also provides support for the basic debugging system of Freescale based on P&E debugger. The project named "integration_multi" is a draft project to be considered as an example of MPC5643L used in multicore configuration. It provides a simple multitasking application distributed among two cores and using inter-processor interrupts and HW semaphores. The "integration" project is the project used as base-line to build up Erika libraries, linker scripts, boot modules and OS configuration files. These files have to be copied to CW project in order to build up a fully system to be integrated in a Codewarrior IDE. A simple bash script is provide as example to perform this copy: copy.sh.</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=ERIKA_Enterprise_Device_Drivers_for_Leopard_MPC5643LERIKA Enterprise Device Drivers for Leopard MPC5643L2014-11-10T13:33:35Z<p>Francesco: Created page with "= Backlog = Il backlog e' su google docs su [https://docs.google.com/spreadsheet/ccc?key=0AsS2INzQeayzdG1yNUVTWUVMSHFtcVJ6ejJnVnh2eHc questo link] --- NO LONGER IN USE --- = Ar..."</p>
<hr />
<div>= Backlog =<br />
<br />
Il backlog e' su google docs su [https://docs.google.com/spreadsheet/ccc?key=0AsS2INzQeayzdG1yNUVTWUVMSHFtcVJ6ejJnVnh2eHc questo link] --- NO LONGER IN USE ---<br />
<br />
= Architecture description (Ref. MPC5643LRM Rev. 9 12 Mar 2012) =<br />
<br />
The Qorivva MPC5643L microcontroller is based on the Power Architecture. All MPC5643L devices are built around a dual-core safety platform, each core is a member of the e200z4 Power Architecture family. Lock step Redundancy Checking Units are implemented at each output of this Sphere of Replication (SoR). ECC is available for on-chip SRAM and flash memories. A programmable fault collection and control unit monitors the integrity status of the device and provides flexible safe state control. The peripheral set provides high-end electrical motor control capability with very low CPU intervention due to the on-chip cross-triggering unit (CTU).<br />
<br />
= Flash Usage =<br />
<br />
There are three address spaces featuring Flash memory of MPC5643L:<br />
<br />
* Low address space (256 KB)<br />
* Mid address space (256 KB)<br />
* High address space (512 KB)<br />
<br />
The MPC5643L flash memory usage has been managed as follow.<br />
<br />
* Block L0 (0x0 - 0x00004000) hosts the boot key of the microcontroler. MPC5643L has several boot sectors, Each boot sector in the flash memory contains at offset 0x00 the Reset Configuration Half-Word (RCHW) that is composed by 2 parts. First part is used to mark this boot sector as "bootable" (0x5A), second part to set VLE/BOOK E mode:<br />
<br />
# 0x15a0000 if the microcontroller runs in "VLE" mode<br />
# 0x05a0000 if the microcontroller runs in "BOOK E" mode<br />
<br />
RCHW is immediately followed by the reset vector of the microcontroller (the address from the microncontroller starts from).<br />
<br />
* Block L1, L2 and L3 (0x00004000 - 0x00020000) hosts Non-Volatile-RAM (NVRAM) data. The policy in charge of managing this flash area is explained in section NVRAM.<br />
* Block L4 and L5 (0x00020000 - 0x00040000) hosts boot code. The content of this flash area is explained in section BOOT.<br />
* Block M0 and M1 (0x00040000 - 0x00080000) hosts calibrations data. The policy in charge of managing this flash area is explained in section CALIBRATIONS.<br />
* Block H0 and H1 (0x00080000 - 0x000C0000) hosts application code. The content of this flash area is explained in section APPLICATION.<br />
<br />
Flash memory is devised as follow:<br />
<br />
[[Image:flash_map_prova.png]]<br />
<br />
== BOOT Flash area ==<br />
<br />
This area will be used to locate Bootloader code. Not provided in this version<br />
<br />
= APPLICATION Flash area =<br />
<br />
Application Flash area hosts user application, drivers and Erika OS.<br />
<br />
== Erika OS ==<br />
<br />
Erika has been provide with the following configurations:<br />
<br />
* '''Single Core (DPM mode)'''. The main feaure of this configuration is that the user has 128 Kbytes of SRAM memory available divided in two memory banks (0x40000000 - 0x4000FFFF and 0x50000000 - 0x5000FFFF). This configuration can be executed from SRAM and from FLASH. The flags used to enable SRAM configurations is: __E200ZX_EXECUTE_FROM_RAM__, if it is not used, FLASH configuration is enabled by default. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:sram_dpm.png]]<br />
<br />
<br />
* '''Single core (Lock-step)'''. The main feaure of this configuration is that the user has 128 Kbytes of SRAM memory available (0x40000000 - 0x0001FFFF). This configuration can be executed from SRAM and from FLASH. In order to enable Lock-step mode the LOCK_STEP flag has to be enabled. This flag has to be combined with __E200ZX_EXECUTE_FROM_RAM__ if the target has to execute from SRAM. If only LOCK_STEP is enabled the target executes from Flash. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:sram_lock.png]]<br />
<br />
<br />
* '''Multicore (DPM mode)'''. The main feature of this configuration is that the user has 64 Kbytes of SRAM memory available for each core. In particular the first 64 Kbytes-bank of SRAM memory (0x40000000 - 0x4000FFFF) is allocated to the master core, this memory area also hosts data shared by both cores. The second 64 Kbytes-bank of SRAM memory (0x50000000 - 0x5000FFFF) is allocated to the slave core. In order to enable this configuration the flag __MSRP__ has to be defined. It has to be combined with __E200ZX_EXECUTE_FROM_RAM__ to have a system running from SRAM. If this flag is not enabled, hence the multicore application is configured to run from Flash. Notice that SRAM configuration is used for a comfortable debug, if the application executes from SRAM, code and data share SRAM banks and Flash is not used, consequently reducing the amount of memory available by user application.<br />
<br />
<br />
[[Image:multi_dpm.png]]<br />
<br />
<br />
'''Additional notes about Erika-multicore in MPC5643L'''<br />
<br />
Erika uses hardware semaphores to guarantee data coherence between master and slave cores. It also used a signalling system based on software interrupts to provides basic inter-core synchronisation mechanism. MPC5643L has two SEMA4 modules, each module has 16 HW semaphores, but these semaphores are not all available by the user since they are used by the operating system to implement a barrier to synchronise both cores after boot sequence. According with these assumptions the 7-th software interrupt is used by signal mechanism and semaphore 0 and 1 of the master's SEMA4 module are used to implement synchronisation barrier, therefore they cannot be used for different purposes. All the remaining semaphores (from 2 to 15 belonging to the master's SEMA4 and all 16 belonging to the slave's SEMA4) and software interrupts (from 1 to 7 of both interrupt controllers) can be used by the user application. Notice that these limitations have to be taken into account only when the system is configured as multi-core. In single-core mode the user is free to use all software interrupts according with his needs, since boot-barrier is not enabled and inter-processor (software) interrupt are not required.<br />
<br />
== Drivers ==<br />
<br />
The implemented drivers are: CanDrv, FlashDrv, SpiDrv, Adc, Pwm and CTU. The details concerning these Drivers are reported in section Device Drivers.<br />
<br />
== User Application ==<br />
<br />
Evidence is not in charge of this part.<br />
<br />
= Board Internal Connections =<br />
<br />
This chapter provides a schema to show connections required for SPI, ADC, CAN (configured as CANDRV_NORMAL), System clock and one PWM signal (PWM0_A1).<br />
<br />
[[Image:board.png]]<br />
<br />
= Device Drivers =<br />
<br />
== Can Driver (CanDrv) ==<br />
<br />
Can Driver is based on Freescale FlexCan present in MPC5643L. Can Driver details will be provided in two distinct sections: configuration and API. Configuration section concerns Can Driver static configuration, that means that Can Driver has to be statically configured by CanCfg module (reference: sources/ApplCfg/CanCfg.c). The API section of the manual shows the set of functionalities featuring this CanDrv implemenation.<br />
<br />
=== CanDrv Configuration ===<br />
<br />
There two levels of CanDrv configuration: FlexCan level and message level. First level is used to configure Can Module with respect the following fields:<br />
<br />
* peripheralEn: it can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that the user wants to enabled or disabled the current Flexcan module. Notice that MPC5643L has two FlexCan modules.<br />
* mode: it can be CANDRV_NORMAL, CANDRV_LOOPBACK or CANDRV_OPENDRAIN. CANDRV_LOOPBACK means that FlexCan module works in loopback mode (look at Reference Manual for details. Ref: MPC5643LRM Rev. 9 12 Mar 2012), CANDRV_OPENDRAIN means that Flexcan is in open drain mode that means that user can connect two FlexCan modules available in MPC564L without the need of external connections.<br />
* autobusonEn: this field can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that the Auto-buson feature is enabled or not (look at Reference Manual for details. Ref: MPC5643LRM Rev. 9 12 Mar 2012)<br />
* peripheralFreq: this field determines FlexCan frequency. There five available values: CANDRV_1MBPS, CANDRV_500KBPS, CANDRV_250KBPS or CANDRV_125KBPS.<br />
* errorHandlingEn: it can be CANDRV_ENABLED/CANDRV_DISABLED according with the fact that user needs error handling capability.<br />
* sampleNumMode: it can be CANDRV_THREE_SAMPLE if user wants to sample the signal three times.<br />
<br />
In CW project and Integration project there are three cases (NORMAL, LOOPBACK and OPENDRAIN) characterised by their configuration parameters. LOOPBACK and OPENDRAIN cases are commented, in order to try these configurations please comment NORMAL mode and uncomment LOOPBACK or OPENDRAIN.<br />
The configuration version currently available in the repository provides FlexCan0 module enabled and FlexCan1 module disabled. All the fields of FlexCan1 are set to CANDRV_DO_NOT_CARE because peripheralEn is set to CANDRV_DISABLED. CanFlex0 is set as a 500 Kbps FlexCan module, with error handling enabled, auto-buson enabled, normal mode and three samples feature enabled.<br />
<br />
=== CanDrv API ===<br />
<br />
'''StdReturnType CanDrvInit(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Initialise canDrv component according with the features set in CanCfg module.<br />
<br />
'''void ManageCanIsr(uint8 isrSourceIndex, uint32 bufferFlags, CanChannelType canChannel);'''<br />
<br />
Input parameters are:<br />
* isrSourceIndex: is the offset in the FLAG1 register representing the isr source;<br />
* bufferFlags: the real isr source;<br />
* canChannel: represents FlexCan0 or FlexCan1<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Initialises Flexcan modules according with the user features set in CanCfg.<br />
<br />
'''StdReturnType CanTransmit(CanTxMsgIndexType msgIndex);'''<br />
<br />
Input parameters are:<br />
* msgIndex: message index taken from all message indexes defined by the user;<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
This function transmits "msgIndex" Can message. Return value of this function is the return value of CanSendManageMsg().<br />
<br />
'''StdReturnType CanPollMessage(CanRxMsgIndexType msgIndex, CanChannelType canChannel);'''<br />
<br />
Input parameters are:<br />
* msgIndex: message index taken from all message indexes defined by the user;<br />
* canChannel: FlexCan channel. It can be Flexcan0 or FlexCan1.<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
If canChannel is different fromFlexcan0 or Flexcan1, return value is STD_NOT_OK. If CanPollMessage() is called for a message for which a isr has been defined and the driver is working in INTERRUPT mode, return value is STD_NOT_OK. For all the remaining scenarios the return value is STD_OK.<br />
<br />
'''void CanDrvEnableInterrupts(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Enable Flexcan interrupts according with the CanCfg flags.<br />
<br />
'''void CanDrvDisableInterrupts(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Disable ALL FlexCan interrupts featuring ENABLED Flexcan modules.<br />
<br />
'''void CanDrvPolling(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function polls all FlexCan messages.<br />
<br />
== Spi Driver (SpiDrv) ==<br />
<br />
A simplified Spi Driver has been provide. Through this driver it is possible to use Spi Module both in Polling mode and Isr mode. APIs are defined as follow:<br />
<br />
'''void SpiTransmit(uint8 channel, uint8 chip_select, uint8 * data, uint8 length);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
* chip_select: is the cuip select (from 0 to 7).<br />
* length: is message length<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function transmits a spi message. Notice that no checks are performed on input parameters.<br />
<br />
'''StdReturnType SpiDrvInit(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
<br />
This function initialises Spi Driver according with flags present in SpiCfg module.<br />
<br />
'''void SpiPoolChannel(const uint8 channel, uint16_t * res);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
* res: is the location of the result<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
This function pools one Spi channel and store the result in the location pointed by res.<br />
<br />
'''uint32 SpiGetMessageLenght(const uint8 channel);'''<br />
<br />
Input parameters are:<br />
* channel: is the Spi channel<br />
<br />
Output parameter:<br />
* message length<br />
<br />
Description:<br />
<br />
Not still developed (NO REQUIREMENTS).<br />
<br />
== Pwm+Adc Drivers (with CTU support) ==<br />
<br />
In PWM driven systems it is important to schedule the acquisition of the state variables with respect to<br />
PWM cycle. State variables are obtained through the following peripherals: ADC, position counter (e.g.<br />
quadrature decoder, resolver and sine-cos sensor) and PWM duty cycle decoder.<br />
The cross triggering unit (CTU) is intended to completely avoid CPU involvement in the time acquisitions<br />
of state variables during the control cycle that can be the PWM cycle, the half PWM cycle or a number of<br />
PWM cycles. In such case the pre-setting of the acquisition times needs to be completed during the<br />
previous control cycle, where the actual acquisitions are to be made, and a double-buffered structure for<br />
the CTU registers is used, in order to activate the new settings at the beginning of the next control cycle.<br />
<br />
'''Problem:''' the main problem featuring this part of the application concerns ADC timing. In order to speed the acquisition up, the<br />
PWM A0 rising edge is used to trigger the Star-Of-Conversion (SOC). This means that whenever the PWM counter ramp reaches the maximum value,<br />
the CTU triggers a ADC acquisition without CPU intervention. This CTU action starts an ADC conversion at the beginning of 50 usec interval (SOC).<br />
Once the ADC conversion terminates at the End-Of-Conversion point (EOC at point 2), a ISR may be raised (but it has been disabled, since a polling strategy has<br />
been preferred). The remaining chunk of time (from EOC to the end of 50 usec), can be used for secondary activities (it is denoted as Free Bandwidth).<br />
At the end of 50-usecs interval, CTU triggers a new acquisition. Notice that the end of 50 usec represents a HARD Deadline, hence it will never being missed.<br />
<br />
[[Image:ctu.png]]<br />
<br />
'''Performance note:''' through a preliminary test, the interval of time between SOC and EOC (the red chunk) assumes a value equal to 790 PWM counter ticks (approximately 14 usec with a 120 Mhz CPU clock).<br />
<br />
=== PWM ===<br />
<br />
MPC5643L has two PWM modules, <br />
A simplified PWM Driver has been provide. Through this driver it is possible to access PWM basic functionalities. MPC5643L has two PWM modules, each PWM module has four PWM devices, for this application only a subset of FlexPWM0 module is used to generate three PWM signals: PWM0_A0, PWM0_A1 and PWM0_A2. APIs are defined as follow:<br />
<br />
'''void InitFlexPWM0(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function initialises FlexPWM0.<br />
<br />
'''void PWM0_AX_load_new_rising_edge(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: match value of the rising edge of X sub-module (X=0,1,2)<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function sets the match value (for rising edge) of PWM0_AX sub-module (X=0,1,2).<br />
<br />
'''void PWM0_AX_load_new_falling_edge(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: match value of the falling edge of X sub-module (X=0,1,2)<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function sets the match value (for falling edge) of PWM0_AX sub-module (X=0,1,2).<br />
<br />
=== ADC ===<br />
<br />
The Analog to Digital Converter (ADC) is a 12 bit Successive Approximation register (SAR) ADC with a mixed capacitive/resistive DAC. This device includes two ADC modules, referred to as ADC_0 and ADC_1. A conversion can be triggered by<br />
software or hardware (CTU), the solution selected for this application is the second one, that is based on CTU support. Currently the system starts the acquisition of 8 different ADC signals of the ADC_0 module as soon as CTU triggers the ADC_0 module. This happens whenever the internal counter of the PWM0 module matches its maximum value.<br />
<br />
External ADC channels:<br />
* 9 external channels on ADC_0 (channels 0..8)<br />
* 9 external channels on ADC_1 (channels 0..8)<br />
* 4 external channels shared between ADC_0 and ADC_1 (channels 11..14)<br />
<br />
This the list of ADC Driver APIs:<br />
<br />
'''StdReturnType InitADC(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* a value to be used to check if function execution has been successfully performed.<br />
<br />
Description:<br />
This function initialises ADC_0 module according with flags present in sources/ApplCfg/AdcCfg/AdcCfg.c. Data structure featuring ADC_0 and ADC_1 is adcConfContainer[2], it is characterised by the followinh data fields:<br />
<br />
* peripheralEn: it can be ADC_ENABLED/ADC_DISABLED to enable/disable ADC_0<br />
* peripheralFreq: it can be ADC_HALF_SYS_FREQ for a working freq. equal to 1/2 of the system freq. It can be ADC_SYS_FREQ if the user requires a working freq. equal to the system freq.<br />
* adcCommandConfigPtr: pointer to a CTU command list.<br />
<br />
<br />
'''uint8 AdcPollChannel(const uint8 adcModule, const uint8 channel)'''<br />
<br />
Input parameters are:<br />
* adcModule: it can be ADC__0 or ADC__1<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function pools the couple "ADC module and channel" represented by adcModule and channel.<br />
<br />
=== CTU (Cross Triggering Unit) ===<br />
<br />
The CTU in this context is used to synchronises the Star-Of-Conversion of the ADC0 channel to the PWM0 counter rising edge , this has been guaranteed without any CPU intervention. CTU has to be initialised in order to accomplish this requirement. All the initialization parameters are collected in one API:<br />
<br />
'''void InitCTU(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function initialises CTU to address the problem shown at the beginning of section "Pwm+Adc Drivers (with CTU support)".<br />
<br />
== Stm Driver ==<br />
<br />
Driver supporting basic STM (System Timer Module) functionalities. In the Erika repository is also provided a AUTOSAR-like version of STM Driver. This is the list of APIs featuring this STM basic driver:<br />
<br />
'''void mpc5643l_stm_freeze_on(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Enable freeze mode option of STM timer. If enabled, when system switches to debug mode, timer stops running.<br />
<br />
'''void mpc5643l_stm_freeze_off(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
<br />
Disable freeze mode option of STM timer. If disabled, when system switches to debug mode, timer continues to increment.<br />
<br />
'''void mpc5643l_stm_set_prescaler(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: prescaler value<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function set STM prescaler<br />
<br />
'''void mpc5643l_stm_select_channel(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be use<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function select STM timer to use<br />
<br />
'''void mpc5643l_stm_unselect_channel(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This function deselects a specific STM channel.<br />
<br />
'''void mpc5643l_stm_channel_cmp(unsigned int ch, unsigned int val);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
* val: comparator value<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
This set a comparator for a specific STM channel<br />
<br />
'''void mpc5643l_stm_clear_int(unsigned int ch);'''<br />
<br />
Input parameters are:<br />
* ch: channel to be unselected<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Clear interrupt for a specific STM channel<br />
<br />
'''void mpc5643l_stm_set_counter(unsigned int val);'''<br />
<br />
Input parameters are:<br />
* val: set the counter of the STM<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Set STM counter value<br />
<br />
'''void mpc5643l_stm_enable(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Enable STM<br />
<br />
'''void mpc5643l_stm_disable(void);'''<br />
<br />
Input parameters are:<br />
* No input parameters<br />
<br />
Output parameter:<br />
* No output parameters<br />
<br />
Description:<br />
Disable STM<br />
<br />
= Lauterbach Support =<br />
<br />
The reference debugging solution for MPC5643L is Lauterbach. In the Erika tree (look at pkg/mcu/freescale_mpc5643l/cfg) is collected a set of Lauterbach sripts for single and multicore configurations. Such a scripts also provide support for execution from SRAM and Flash, in VLE and BookE mode. MPC5643L provides the capability to work in lock-step mode, for this reason a script to pass from/to DPM/lock-step mode is provide (set_lsm_dpm.cmm). To launch this script, user have to launch Lauterbach Tracer first (for instance by editing "t32mppc" in Linux prompt, or equivalent command under Window), and then editing "do set_lsm_dpm.cmm" in the Lauterbach command prompt. This script provides several functionalities, but the only functionality addressed by this manual is the one to switch from/to lock-step/DPM mode. Once the user launches this script the following window appears:<br />
<br />
<br />
[[Image:set_lock_step.png]]<br />
<br />
<br />
Red box shows two buttons to select lock-step or DPM mode. For instance, in this case we have a system set as DPM, if we would like to switch to LSM mode, we have to press the LSM button, and then press "PROGRAM". After this action, a confirmation window will be shown, press "YES" to confirm:<br />
<br />
<br />
[[Image:lock_step_ok_button.png]]<br />
<br />
<br />
If the programming task is successfully accomplished, the following window will be shown. Press "OK" to terminate the script.<br />
<br />
<br />
[[Image:lock_step_ok_message.png]]<br />
<br />
<br />
<span style="color:#ff0000"> IMPORTANT NOTE: </span> in order to make the switch-mode effective, a power-cycle has to be done. Therefore power your board off, and then power it on.<br />
<br />
= Project structure =<br />
<br />
The project is structured in three branches: CW, integration and integration_multi. The remaining directories are not relevant. CW project is based on Codewarrior IDE and works both for Linux and for Windows, it also provides support for the basic debugging system of Freescale based on P&E debugger. The project named "integration_multi" is a draft project to be considered as an example of MPC5643L used in multicore configuration. It provides a simple multitasking application distributed among two cores and using inter-processor interrupts and HW semaphores. The "integration" project is the project used as base-line to build up Erika libraries, linker scripts, boot modules and OS configuration files. These files have to be copied to CW project in order to build up a fully system to be integrated in a Codewarrior IDE. A simple bash script is provide as example to perform this copy: copy.sh.</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-10T10:25:24Z<p>Francesco: /* Testing environment */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard)<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
Additional notes: a demo using Leopard and CCP protocol to monitor a variable can be found under "examples/ppc/templates/leopard/ccp_leopard", while CCP implementation is under "contrib/Ccp"<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-10T10:09:50Z<p>Francesco: /* Testing environment */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard)<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
Additional notes: a demo using Leopard and CCP protocol to monitor a variable can be found under "examples/ppc/ccp_leopard", while CCP implementation is under "contrib/Ccp"<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-09T09:09:08Z<p>Francesco: /* Subset of the standard implemented */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by Erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard)<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-09T09:08:51Z<p>Francesco: /* Subset of the standard implemented */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privided by erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard)<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-09T09:05:33Z<p>Francesco: /* Testing environment */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privide by erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard)<br />
<br />
= Testing environment =<br />
<br />
The environment adopted by third party companies is:<br />
<br />
* ATI Vision 3.3 (Used as CCP Master tool);<br />
* Kvaser USBCan II (but Peak System PCAN-USB is succesfully used too);<br />
* MPC56XX EVB as Target board (with a MPC5643L on the doughter board)<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-09T09:01:26Z<p>Francesco: /* Target supported */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privide by erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
<br />
The only target freely supported at this moment is the Freescale MPC5643L (Leopard)<br />
<br />
= Testing environment =<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-09T09:00:26Z<p>Francesco: /* Subset of the standard implemented */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privide by erika distribution is limited to the following subset of CCP commands:<br />
<br />
* CONNECT 0x01<br />
* EXCHANGE_ID 0x17<br />
* SET_MTA 0x02<br />
* DNLOAD 0x03<br />
* DNLOAD_6 0x23<br />
* UPLOAD 0x04<br />
* SHORT_UPLOAD 0x0F<br />
* GET_DAQ_SIZE 0x14<br />
* SET_DAQ_PTR 0x15<br />
* WRITE_DAQ 0x16<br />
* START_STOP 0x06<br />
* DISCONNECT 0x07<br />
* SET_S_STATUS 0x0C<br />
* GET_S_STATUS 0x0D<br />
* START_STOP_ALL 0x08<br />
* BUILD_CHECKSUM 0x0E<br />
* MOVE 0x19<br />
* TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
<br />
= Testing environment =<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-09T08:59:42Z<p>Francesco: /* Subset of the standard implemented */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
The implementation privide by erika distribution is limited to the following subset of CCP commands:<br />
<br />
CONNECT 0x01<br />
EXCHANGE_ID 0x17<br />
SET_MTA 0x02<br />
DNLOAD 0x03<br />
DNLOAD_6 0x23<br />
UPLOAD 0x04<br />
SHORT_UPLOAD 0x0F<br />
GET_DAQ_SIZE 0x14<br />
SET_DAQ_PTR 0x15<br />
WRITE_DAQ 0x16<br />
START_STOP 0x06<br />
DISCONNECT 0x07<br />
SET_S_STATUS 0x0C<br />
GET_S_STATUS 0x0D<br />
START_STOP_ALL 0x08<br />
BUILD_CHECKSUM 0x0E<br />
MOVE 0x19<br />
TEST 0x05<br />
<br />
This implementation has been succesfully used by third party companies in conjunction with commercial suite (like ATI Vision)<br />
<br />
= Target supported =<br />
<br />
= Testing environment =<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Open-source_CAN_Calibration_Protocol_(CCP)_implementationOpen-source CAN Calibration Protocol (CCP) implementation2014-11-09T08:53:57Z<p>Francesco: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
<br />
[Reference: CAN Calibration Protocol - Version 2.1. Author: H. Kleinknecht. Distribution: public] "The Controller Area Network CAN is a joint development of Robert Bosch GmbH and Intel<br />
Corporation. CAN is used in many high-end automotive control systems like engine management as well as in industrial control systems. Controller chips for CAN are available<br />
from various semiconductor manufacturers. The CAN Calibration Protocol is part of the ASAP standards. It was developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems,<br />
and is used in several applications in the automotive industry. The CCP was taken over by the ASAP working group and enhanced with optional functions."<br />
<br />
= Subset of the standard implemented =<br />
<br />
= Target supported =<br />
<br />
= Testing environment =<br />
<br />
= Acknowledgements =<br />
This work has been developed in collaboration with Piaggio & C. Spa and Evidence, and published in the Paper<br />
<br />
<pre><br />
Towards an Open Source Framework for Small Engine Controls Development<br />
Paolo Gai, Francesco Esposito, Riccardo Schiavi, Evidence Srl; Marco Di Natale, Scuola Superiore S. Anna; Claudio Diglio, Michele Pagano, Carlo Camicia, Luca Carmignani, Piaggio & C SpA, SAE SETC 2014, Pisa, Italy, paper ID 2014-32-0070<br />
</pre></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Freescale_PPC_e200_(MPC_56xx)Freescale PPC e200 (MPC 56xx)2014-09-12T06:56:24Z<p>Francesco: /* MCUs */</p>
<hr />
<div>= Freescale PPC e200 (MPC 56xx) support =<br />
ERIKA Enterprise supports the PPC e200 family microcontrollers.<br />
The support for RT-Druid is available starting from release 1.5.0.<br />
The support includes: <br />
# Support MPC5674F (e200z7). MPC5668G (e200z6) is supported in version 1.6.0; version 1.6.1 will support both cores (z6 and z0) of the MPC5668G (already available on the [[ERIKA Enterprise and RT-Druid SVN Access|Subversion repository]]). Support for MPC5643L (e200z4).<br />
# Support for the WindRiver DIAB and Freescale CodeWarrior compilers.<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers<br />
** WindRiver DIAB C Compiler 5.5.1 and 5.8.0.<br />
** Freescale CodeWarrior:<br />
*** Windows: CodeWarrior Development Studio for MPC55xx/56xx 2.7<br />
*** Linux: CodeWarrior Development Studio for MCU 10.2<br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: Currently limited to the MPC5668G and MPC5643L, it follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ Autosar]: two instances of the operating systems run on the two cores, and communication between cores is performed with a few APIs and shared memory.<br />
<br />
* MMU Handling<br />
** Static global mappings to let all the application see all the memory/peripherals in the system; no memory protection is implemented and all the code is executed in supervisor mode.<br />
<br />
== Host Configuration ==<br />
<br />
* RT-Druid requires Java 1.6.<br />
* It is possible to use a version of ERIKA more recent than the one provided with RT-Druid; just download the ERIKA tree from the repository (see [[ERIKA Enterprise and RT-Druid SVN Access]]) and point the '''ERIKA_FILES''' environment variable to its location; see [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]] for some caveats.<br />
<br />
=== Wind River Diab ===<br />
* Compiler: The compiler commands (dcc, das, dld, and dar) are assumed to be reachable from the $PATH. If a specific version of them has to be used it must be specified in pkg/cfg/arch/cc_z7diab.mk<br />
* Operating system: The PPC e200 port has been developed under Debian testing/unstable as of May 2010; the only known requirement is Java 1.6 to run RT-Druid.<br />
* In the reference environment, the Diab toolchain was located in /opt/case/diabdata/<version> and Eclipse in /opt/eclipse. No hard requirement is made by the build system, as specified above. <br />
<br />
=== Freescale CodeWarrior ===<br />
*Compiler: The compiler directory can be specified using the environment variable '''PPC_CW_BASEDIR'''; this directory must contain the directories ''PA_Support'', and ''PA_Tools'' or ''PowerPC_EABI_Tools''. ERIKA makefiles find all the files they need with relatives paths from there. Please notice that makefiles require that the variable '''PPC_CW_BASEDIR''' do not contain any space. An evaluation or a limited version of the compiler can be downloaded from the [http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_DOWNLOADS Freescale Web site].<br />
*Operating system: both Linux and Windows are supported. CodeWarrior support has been developed under Debian Linux and Windows XP, but other (and more recent) versions should work. On Windows, ''Special Edition: CodeWarrior for Microcontrollers 10.5'' is currently used, and on Linux ''CodeWarrior Development Studio for MCU'' version 10.2. On Windows the Cygwin environment is used for ERIKA makefiles, so the '''PPC_CW_BASEDIR''' variable must use forward slashes '/' and must not contain spaces; you can always convert the path with the ''cygpath'' command. For example, in this case the value to use is <code>/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7</code>:<br />
$ cygpath.exe `cygpath.exe -ms "/c/Program Files/Freescale/CW for MPC55xx and MPC56xx 2.7"`<br />
/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7<br />
*OIL file: Currently, an ''EEOPT'' with value '''"__CODEWARRIOR__"''' must be specified in the OIL file. See [[#OIL file configuration]] for more details.<br />
<br />
== Target configuration and programming==<br />
<br />
* ERIKA is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]<br />
* ERIKA supports the Freescale MPC5674F, MPC5668G and MPC5643L MCUs (we have been able to run it on an MPC56XX and others; Freescale MCUs are really very similar).<br />
* At system boot the interrupt controller is set up to work in Software Vector Mode, and all the interrupts are associated to default handlers. The kernel does not use any specific device/interrupts, although for testing purposes it is possible to use the decrementer and some gpios as interrupt sources. All the code is executed from flash, all the data sections are loaded into the SRAM at boot time (the MMU is configured to provide 1:1 mappings for code running in system mode for all the sensible regions, like flash, sram and device registers).<br />
* The version in the repository supports both FLE and VLE modes.<br />
* The scripts generated by the build process are compatible with Lauterbach v200912. The commands generated to setup the NEXUS port are not compatible with older releases of the Lauterbach software. In case you hit this problem, remove the NEXUS.* lines from the generated scripts, ad set up the port according to the Lauterbach version you are using.<br />
* Target registers are used according the PPC ABI described in the DIAB manual.<br />
* The stack fill pattern is configurable at compile time, but is assumed to be 0xa5.<br />
* For Osek conformance classes, which support TerminateTask(), each running task requires 96 bytes of stack. <br />
For multistack configurations, 76 bytes are required on each stack for context switching. You can add this numbers to the requirements of your application to estimate task usage.<br />
* Stack pointer is aligned at 16 byte (fixed in version 1.6)<br />
<br />
=== MCUs ===<br />
* The MCUs supported are currently the following:<br />
** MPC5674F (Freescale Mamba)<br />
** MPC5668G (Freescale Fado)<br />
** MPC5643L (Freescale Leopard)<br />
** MPC5777C (Freescale Cobra55) Not publicly released. If interested please contact us at info@evidence.eu.com<br />
** SPC574K (STMicroelectronics K2) Not publicly released. If interested please contact us at info@evidence.eu.com<br />
<br />
===OIL file configuration===<br />
For more information about configuration through OIL file, see [[Tutorial: RT-Druid and OIL basics]]. Here only the e200zX-specific part of OIL is described.<br />
;CPU (CPU_DATA)<br />
: CPU must be set to E200ZX. The exact model is specified with the '''MODEL''' item (supported values are '''E200Z0''', '''E200Z6''' , '''E200Z7''' and '''E200Z4'''. Generation of VLE code can be selected by setting '''VLE''' to '''TRUE'''; please notice that all the application and the OS code must have the same setting, as ERIKA makefiles do not support mixed programs. Size in byte of the shared stack can be specified with the optional '''SYS_STACK_SIZE''' item.<br />
: Example of a CPU_DATA section:<br />
CPU_DATA = PPCE200ZX {<br />
ID = "MainCpu";<br />
MODEL = E200Z7;<br />
APP_SRC = "main.c";<br />
MULTI_STACK = FALSE;<br />
VLE = FALSE;<br />
SYS_STACK_SIZE = 512;<br />
};<br />
:On multicore systems, one CPU_DATA instance can exist for each core. They must have different '''ID'''s. See [[ERIKA multicore support]] for more details about multicore systems on Erika.<br />
;MCU<br />
: MCU support is present for MPC5674F ,MPC5668G and MPC5643L. The only item supported is '''MODEL''', which can be either '''MPC5674F''', '''MPC5668G''' or '''MPC5643L'''. Most of the differences produced by this setting affect memory map and Lauterbach scripts.<br />
: Example:<br />
MCU_DATA = PPCE200ZX {<br />
MODEL = MPC5674F;<br />
};<br />
;System Timer<br />
Erika on PowerPC has a system timer based on PowerPC Decrementer. This feature is available for all supported MCUs: MPC5674F (Mamba), MPC5668G(Fado) and MPC5643L (Leopard). System time also requires CPU_CLOCK field to be set on CPU_DATA, hence CPU_CLOCK value must be added in CPU_DATA configuration to have a system timer configured.<br />
This is an example to configure Decrementer as System Timer:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_DECREMENTER";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "DECREMENTER";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
<br />
Furthermore for MPC5643L (Leopard) is available a system timer based on Freescale STM (System Timer Module), that is a device available in several Freescale PowerPC MCUs. In this case the following configuration must be take into account:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_STM";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
...<br />
...<br />
<br />
<br />
;EEOPTs<br />
: See also [[EEOPT]] for common EEOPTs.<br />
: Special options for the PPC e200 ERIKA porting can be specified through '''EE_OPT''' items in the '''OS''' section (please notice that the value for an '''EE_OPT''' is a string, so double quotes (") must be added around the values in this list.<br />
:; EE_SYSTEM_TIMER_DEVICE_DECREMENTER (see system timer section above)<br />
:; EE_SYSTEM_TIMER_DEVICE_STM (available only for MPC5643L, see system timer section above)<br />
:;EE_ISR_DYNAMIC_TABLE<br />
::Used to enable dynamic ISR table support that let register ISR handlers at runtime calling <code>EE_e200z7_register_ISR</code>.<br />
:;__E200ZX_EXECUTE_FROM_RAM__<br />
:: When specified, a linker script is used that maps both code and data in the RAM space. Executables produced with this option can be used only together with a debugger that loads the program in memory. By default, code and constant data are mapped to Flash, data to RAM.<br />
:;__CODEWARRIOR__<br />
:: Invoke Freescale CodeWarrior compiler. See [[#Freescale CodeWarrior]] for information on how to configure the compiler. The default compiler is Wind River Diab; see [[#Wind River Diab]] for configuration.<br />
:;__USE_CUSTOM_LINKER_SCRIPT__<br />
:: Don't use the dafault linker script. Users can direct the linker to use their own linker script by setting the <code>LDFLAGS</code> variable. Example:<br />
OS EE {<br />
EE_OPT = "__USE_CUSTOM_LINKER_SCRIPT__";<br />
LDFLAGS = "../my_linker_script.ld";<br />
};<br />
:;__USE_CUSTOM_CRT0__<br />
:: Don't use Erika default crt0. Users can provide their own crt0 by adding source files in the usual way (APP_SRC in the OIL file).<br />
;;__MINIMAL_CC_OPTIONS__<br />
:: Enable only the compiler flags absolutely needed to compile Erika, so users can easily add their preferences in CFLAGS.<br />
;;__EE_USE_MMU__<br />
:: Enable the MMU support. The MMU can be configured by calling <code>EE_e200zx_mmu_setup()</code>. See the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> for more details. An example configuration can be found in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt>.<br />
;;__EE_CRT0_INIT_MMU__<br />
:: Initialize the MMU from the crt0. See <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt> for an example, and the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt>.<br />
;;EE_NO_LIBEE<br />
:: To not generete the kernel library '''libee.a''' but link all the objects files (kernel + application) directly in an elf file. This option is useful to try Erika with CodeWarrior compiler with an evaluation license, because the archiver is not enabled with this license.<br />
;;DEBUG<br />
:: On this architecture, enabling debug symbols does not inhibit optimization.<br />
;;MPC5643L_STD_SW_MMU_CONFIG"<br />
:: This EE_OPT is valid only for MPC5643L (Leopard) and provides a standard (and in most cases sufficient) MMU configuration. This option is useful expecially running your code from FLASH where Debugger does not initializes the MMU for you.<br />
;;EE_LAUTERBACH_DEMO_SIM<br />
:: This option is available only for Mamba (MPC5674F), for details please take a look at DEMO_ErikaSim in the directory of templates. It causes the generation of Lauterbach scripts to use with Lauterbach simulator.<br />
<br />
There are a few examples in the ERIKA code base that can be used as a starting point for new projects. Examples include also a makefile, which can be used to compile a project without a need of an IDE. The makefile runs RT-Druid non-interactively, and requires the environment variable '''RTDRUID_ECLIPSE_HOME''' to point to the Eclipse directory where RT-Druid is installed.<br />
<br />
Examples can be accessed as templates in RT-Druid (see [[How to create, compile and debug an application for Freescale MPC5674F]]), or directly in the source code: [http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/ examples/ppc/].<br />
<br />
In the first version of ERIKA and RT-Druid supporting e200zX, the only e200-specific setting in the OIL configuration file was the CPU_DATA value, which had to be set to '''MPC5674F''' instead of '''PPCE200ZX'''. This not supported any more.<br />
<br />
=== APIs ===<br />
* List of functions (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_irq.h?view=markup pkg/cpu/e200zx/inc/ee_irq.h]</tt> for prototypes and other details):<br />
** EE_e200z7_register_ISR(level, handler, priority): Associate <tt>handler</tt> to the IRQ <tt>level</tt>, with the given <tt>priority</tt> (available only if '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' is set).<br />
** EE_e200z7_setup_decrementer(delay): Configure the decrementer to raise an interrupt every <tt>delay</tt> cycles.<br />
** EE_e200z7_setup_decrementer_oneshot(delay): Configure the decrementer to raise an interrupt <tt>delay</tt> cycles after invocation.<br />
** EE_e200z7_stop_decrementer(): Stop the decrementer from generating interrupts.<br />
** EE_e200zx_setup_fixed_intv(bitpos): Enable the fixed-interval interrupt.<br />
** EE_e200zx_stop_fixed_intv(): Disable the fixed-interval interrupt.<br />
** EE_e200zx_mmu_setup(entries, count): MMU initialization.<br />
<br />
Note: notice that the *_e200z7_* is slightly misleading since it seem to refer only to e200z7 family, it is a legacy name convention when the only supported architecture by Erika was Z7. Currently even Z0, Z4 and Z6 are supported hence these functions can be used for such architectures, although it refers to *_e200z7_*.<br />
<br />
====Interrupts====<br />
<br />
There are two way to configure ISR. The standard way is the static way with OIL configuration (example):<br />
<br />
ISR DecrIsr {<br />
CATEGORY = 2;<br />
ENTRY = "DECREMENTER";<br />
};<br />
<br />
ISR FixedIntvIsr {<br />
CATEGORY = 2;<br />
ENTRY = "FIXED_INTV";<br />
HANDLER = "fixed_intv_handler";<br />
};<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
ENTRY = "0";<br />
};<br />
ISR IsrMedium {<br />
CATEGORY = 2;<br />
PRIORITY = 2;<br />
ENTRY = "1";<br />
};<br />
<br />
ISR IsrHigh {<br />
CATEGORY = ;<br />
PRIORITY = 3;<br />
ENTRY = "2";<br />
HANDLER = "isr_high_handler";<br />
};<br />
<br />
In static ISR table handling mode there's full support for both ISR1 and ISR2 for '''external interrupt'''. To register an handler you should use the suitable macro ('''ISR1''' or '''ISR2''') passing the value of '''HANDLER''' field or the '''ISR name''', in case the former is missing. The configuration field '''ENTRY''' declare the position of the handler inside the vector table (the example show three handlers that get the first three positions in vector, corrisponding to the first three software interrupt request). Priority field corripsond to interrupt priority value set to corrisponding Interrupt Controller Priority select registers ('''INTC.PSR[(ENTRY)] = PRIORITY'''), the values have to be inside [0..15] range.<br />
<br />
There is direct support for two cpu '''internal exceptions''', those generated by the time base facilities: decrementer and fixed interval timer ('''ENTRY = "DECREMENTER"''' and '''ENTRY = "FIXED_INTV"'''' respectively.). Support for Watch-Dog timer will be added. To register an handler for internal interrupt you have to use '''ISR1_INT''' or '''ISR2_INT''' (two different couple of macros are needed to issue EOI, End Of Interrupt, only for external interrupts). Priority field in configuration have no meaning for internal interrupts.<br />
<br />
You can register handler by code dinamically with with the <code>EE_e200z7_register_ISR()</code> described above. To enable dynamic ISR table support you must declare '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' configuration OIL file. The '''first 16 level''' of dynamic table are reserved for '''internal exceptions''' handlers, so you have to add this offset to the '''ENTRY''' value of the static approach to register an handler to the same interrupt source.<br />
<br />
ISRs (Interrupt Service Routines) are just void functions with no arguments. For external interrupts (IVOR4), the EOI (End Of Interrupt) is issued by ERIKA's handler; user ISRs need not bother about that.<br />
<br />
====Multicore support (MPC5668 and MPC5643L)====<br />
* Functions used for multicore support on MPC5668 (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5668/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5668/inc/ee_dual.h]</tt> for prototypes and other details):<br />
** EE_mpc5668_start_z0(f): Enable the z0 CPU.<br />
<br />
The same paradigm of multicore support available for MPC5668G, is also available for the MPC5643L, (for details see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5643l/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5643l/inc/ee_dual.h]</tt>). Likewise MPC5668G, in order to start the slave core, a EE_mpc5643l_start_slave(f) call has to be provided at startup (typically in main function) immediately before the StartOS().<br />
<br />
=== Boards ===<br />
* ERIKA has been developed on an '''Axiom MPC5674evbfxmb evaluation board'''. This evaluation board has the MAMBA microcontroller (Freescale MPC5674F)<br />
** The kernel has no dependency on the board itself, but some of its functionalities can be used for debugging purposes. Including file "pkg/board/axiom_mpc5674fxmb/inc/ee_board.h" the following functions can be used:<br />
*** EE_leds_init(): which sets up the GPIOs associated with the leds.<br />
*** EE_EE_leds(mask): which turns the i-th led on or off depending on the state of the i-th bit in the mask passed as an argument.<br />
*** EE_led_<X>_on()/EE_led_<X>_off(): turns led X on or off.<br />
*** EE_buttons_disable_interrupts(button): disables the interrupt associated to the given button.<br />
*** EE_buttons_enable_interrupts(button): enables it.<br />
*** EE_buttons_clear_ISRflag(button): acknowledges the interrupt coming from the given button.<br />
*** EE_button_get_B<X>(): gets the status of button X.<br />
*** EE_buttons_init(): initializes the GPIOs associated to buttons.<br />
** The functions above are available if, respectively, __USE_LEDS__ and __USE_BUTTONS__ are defined upon inclusion of ee_board.h<br />
** The connections are assumed to be the following:<br />
*** GPIO 147-150: connected to LED0-3. Looking at the pins on the EVB:<br />
**** ETPUB1 -> USER_LED1<br />
**** ETPUB2 -> USER_LED2<br />
**** ETPUB3 -> USER_LED3<br />
*** GPIO 450: connected to BUTTON0 (ETPUC9 -> USER_DEV1)<br />
<br />
* Erika is available for the '''Freescale MPC5668EVB Evaluation Board'''. This evaluation board has the FADO microcontroller (Freescale MPC5668G)<br />
** for this board the are no available support for leds or buttons.<br />
<br />
* Erika is available for '''Freescale MPC564xLEVB Evaluation Board'''. This evaluation board has the LEOPARD microcontroller (Freescale MPC5643L)<br />
** for this board there is the same set of primitives defined for "Axiom MPC5674evbfxmb" board, hence a basic support for leds and button is available.<br />
<br />
== Multicore support ==<br />
<br />
In the ERIKA multicore support for PPC e200 there are a few aspects specific to the PPC e200 architecture, and they are described here. Please refer to [[ERIKA multicore support]] for general information on ERIKA multicore systems.<br />
<br />
The PPC evaluation board supported by Erika Multicore is the Freescale MPC5668G/E Evaluation kit, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5668GKIT. The multicore support is also provided for MPC5643L with the Freescale evaluation board MPC564xL EVB, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=XKT564L.<br />
<br />
In multicore configuration, is it possible running both instances of the operating system both in RAM and Flash. For instance on MPC5668G, the internal SRAM is partitioned statically in two: memory from 0x40000000 to 0x4001FFFF is reserved to the first core and shared variables, while memory from 0x40020000 to 0x4003FFFF is reserved to the second core. 0x40020000 is used as the starting address of the second core. A similar approach is available for MPC5643L. In order to customize such memory assignments please refer to memory0.ld and memory1.ld files in "erika/pkg/mcu/freescale_mpc56XX/cfg/multicore" (where XX=43l for Leopard and XX=68 for Fado).<br />
<br />
Shared variable data is allocated in a single section (<tt>.mcglobald</tt>). Access to this section must be performed without cache, or the OS may malfunction. ERIKA crt0 does not enable cache; if you want to enable it, you should also make sure that the <tt>.mcglobald</tt> section is allocated on a page on its own by the linker script, and that the MMU is configured to mark such page as non-cached. <br />
<br />
The OS uses two software interrupts (6 and 7) and two hardware semaphores (0 and 1) of the MPC5668G to handle inter-core communication. They are initialised inside <code>StartOS()</code>. While all the other software interrupts and semaphores are available for user applications, those used by the OS should not be meddled with by user code. It is okay to briefly mask the interrupts with higher-priority interrupts or by disabling interrupts. In case of MPC5643L, as the microcontroller has two different interrupt controllers (one for each core), SW interrupt number 7 is used for both cores. Even if the MPC5643L has two SEMA4 modules, only the first module (the one associated to the master core) is used for this mechanism, this means that semaphores 0 and 1 of the first SEMA4 module are used for synchronisation (as in MPC5668G), while the remaining semaphores of the first SEMA4 module and all semaphores belonging to the second SEMA4 module are available for user applications.<br />
<br />
Examples of multicore applications are in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/ examples/ppc/dual_examples]</tt>. In particular, <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/mono_activate01/ examples/ppc/dual_examples/mono_activate01]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/multi_event01/ examples/ppc/dual_examples/multi_event01]</tt> are complete applications, nearer to real-world usage.<br />
<br />
Erika multicore for PowerPC supports AUTOSAR OS-like functionalities. For details please see the following page (but take into account that these features have not been published yet):<br />
[[Erika AUTOSAR OS]]<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for PPC e200 produces a Lauterbach Trace32 configuration file (<tt>t32.cmm</tt>) and a ORTI description file (<tt>system.orti</tt>) inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger, please issue <code>t32mppc</code> from the output directory. The ERIKA build system honors the <tt>T32SYS</tt> environment variable, if set.<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named <tt>start.sh</tt>) is produced in the output directory. To run the debugger, please issue <code>start.sh</code> from the output directory. The script creates two instances of the debugger, one for each core. For instace when MPC5668G is turned on, only the first (Z6) core is enabled. In order to simulate the real setup, the debugger connected to the second (Z0) core does not enable its core, but it is responsibility of the code running on the Z6 core to enable the Z0 core (this is different from the example script for MPC5668G distributed with the Lauterbach Trace32 software). Nonetheless, the startup script loads all the code and the debug symbols for both core and both debugger instances. In a typical debugging session, you start the execution of the code on the Z6 core from its debugger, and then, when the Z0 core has become active, start also the code on the Z0 core from the Z0 debugger. The barrier inside <code>StartOS()</code> comes handy to synchronize the code running on the two cores. The <tt>start.sh</tt> script runs only on Linux; currently the ERIKA build system does not support Windows to run Trace32 for e200 multicore systems. A similar approach has been adopted for MPC5643L.<br />
<br />
==Internals==<br />
<br />
===Interrupts===<br />
<br />
Interrupt handling in PPC e200 ERIKA uses software vector mode and a single entry point for all interrupts and exceptions, which is <code>EE_e200z7_irq()</code>. This function calls the user ISR and issues the end-of-interrupt for external interrupts; when the served interrupt is not nested, i.e., it interrupted a task directly, <code>EE_e200z7_irq()</code> also calls the scheduler before returning.<br />
<br />
This scheme of IRQ handling can be changed by rewriting the crt0 and changing the IVOR setup. In this way it is possible, for example, to use hardware vector mode. Please note that it is important that the end-of-interrupt be issued before calling the scheduler, as the scheduler may not return when a new task is to be scheduled.<br />
<br />
===Use of non volatile registers in Erika PowerPC===<br />
<br />
Some Erika RTOS assembly modules in PowerPC use non volatile registers for their internal purposes (r14-r31). Such modules are:<br />
<br />
* ee_e200zx_contex.S - This module is in charge of managing context switch for multistack on e200zx. In this module r14-r31 are saved and restored in a prologue and epilogue;<br />
* ee_oo.S - This module is in charge of saving and restoring registers for Osek TerminateTask() on e200zx. In this module r14-r31 are saved and restored in a prologue and epilogue;<br />
* ee_entry.S - This module handles exception entry points and hardware setup for the e200zx. In this module the istruction stmw uses r28-r30 to initialize SRAM. This code is stripped if a custom ISR table is used (see EE_ISR_EXTERNAL_TABLE for details);<br />
* ee_boot.S - This module represents boot sequence for PowerPC MCUs. The erika boot sequence accesses non volatile registers in init phase. This code can be removed from build process (see __USE_CUSTOM_CRT0__ for details).<br />
<br />
The use of r14-r31 registers is limited, just few lines of code. But this information is relevant in case advanced features of some compilers are used, (e.g.: to define additional non-standard SDAs, Small Data Area). For instance Windriver Diab compiler has the REGISTER directive in the linker script to fullfill this requirement. If this non-standard approach is not required this information can be neglected. It is provided in order to give the position of such code whenever the use of non volatile registers (r14-r31) is necessary for non-standard purposes. For details please refere to your compiler documentation.<br />
<br />
'''Assumption for future development:''' additional SDA base addresses will be stored starting from register r14<br />
<br />
== Download and install of Eclipse, RT-Druid, and ERIKA source ==<br />
<br />
To build an ERIKA application you need:<br />
* ERIKA source code<br />
* RT-Druid and a hosting Eclipse<br />
* Some command-line tools<br />
<br />
=== ERIKA source code ===<br />
<br />
ERIKA source code is bundled with RT-Druid. ERIKA for PPC e200 honors the definition of '''ERIKA_FILES''', so you can use the latest version of ERIKA as explained in [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]].<br />
<br />
=== Eclipse and RT-Druid in one piece ===<br />
<br />
A complete version of an Eclipse installation together with the RT-Druid plugin can be downloaded from this page:<br />
http://erika.tuxfamily.org/erika-for-multiple-devices.html. Please make sure to use a version not older than 1.6.0 beta. See also [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application]].<br />
<br />
=== Eclipse and RT-Druid piece by piece ===<br />
<br />
Alternatively, if you already have a copy of Eclipse or you want to use a version of Eclipse different from the one provided by the page above, you can follow this procedure.<br />
* To download the e200 plug-in for Eclipse refer the following site: [http://download.tuxfamily.org/erika/webdownload/rtdruid_beta Plug-in download site].<br />
Procedure for installation:<br />
* Step 0:<br />
: Get ''Eclipse'' and required plug-ins;<br />
: Where possible, the suggestion is to download the ''all in one update site'' and use the eclipse update manager or to use the eclipse update manager directly on a web site;<br />
:* Eclipse<br />
:: If you don't have any eclipse installations, you can download eclipse with cdt already installed from [http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/heliossr1 Eclipse IDE for C/C++].<br />
:: It is also possible use an already installed distribution of eclipse or to download one (for example from [http://www.eclipse.org/downloads Eclipse Downloads]) and then add all missing plug-ins.<br />
:* EMF<br />
:: The main page to download EMF is [http://www.eclipse.org/modeling/emf/downloads/?project=emf Eclipse Modeling Framework].<br />
:: The version to download is related to the eclipse version: eclipse 3.3 -> emf 2.3 , eclipse 3.4 -> emf 2.4, eclipse 3.5 -> emf 2.5, eclipse 3.6 -> emf 2.6. <br />
:: The list of required plugins is:<br />
::: org.eclipse.emf.common<br />
::: org.eclipse.emf.ecore<br />
::: org.eclipse.emf.edit<br />
::: org.eclipse.emf.common.ui<br />
::: org.eclipse.emf.edit.ui<br />
:: Clearly it is possible to install more plugins, like the whole emf runtime or sdk<br />
:* CDT<br />
:: The main page to download CDT is [http://www.eclipse.org/cdt/downloads.php CDT Downloads].<br />
:: Also here, the version to download is related to eclipse version. <br />
:: In this case is required only the cdt runtime plugin.<br />
: [http://erika.tuxfamily.org/forum/viewtopic.php?f=6&t=651&sid=89784e2d97765c3f1c41f6e3c049437a#p727 Forum Post (in italian) about installing the Eclipse plugins]<br />
* Step 1:<br />
: Open ''Eclipse'';<br />
: From the menu ''Help'' select ''Install New Software...'';<br />
: Add with the button ''Add...'' the reference site mentioned above (fill the Location field with this: http://download.tuxfamily.org/erika/webdownload/rtdruid_beta);<br />
: Tick all plug-ins related to RT-Druid core and to Erika Enterprise, then click on the button ''Next'' to install them;<br />
: Restart Eclipse;<br />
* Step 2:<br />
: From the menu ''File'' select ''New'' and then RT-Druid Oil and C/C++ Project;<br />
: From the Project menu select one of the available e200 demo tests;<br />
: Then click on the project name with the right mouse button and build to obtain the elf object module for debugging;<br />
<br />
=== Additional software ===<br />
<br />
ERIKA uses GNU make and some command-line utilities to build programs. You need the following tools (please notice that only the less common commands are listed here; very common commands that are present in any Unix/POSIX system like ''ls'' are not listed for simplicity):<br />
* make (GNU version)<br />
* gawk (GNU AWK)<br />
* sed<br />
* grep<br />
<br />
For Linux the above commands are present in virtually every standard installation; but you can always install them from the respective packages of your distributions.<br />
<br />
For Windows, [http://www.cygwin.com/ Cygwin] is recommended. Please make sure to include the above packages (package names are the same as the tool names).<br />
<br />
== HOWTOs ==<br />
* [[How to create, compile and debug an application for Freescale MPC5674F]]<br />
* [[How to run the MODISTARC regression tests for Freescale MPC5674F]]<br />
<br />
<br />
[[Category:Supported Devices]]</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Black_Box_Regression_testsBlack Box Regression tests2014-07-29T06:35:39Z<p>Francesco: /* More info */</p>
<hr />
<div>This page documents about the Black Box regression tests implemented for ERIKA Enterprise.<br />
<br />
= Main idea =<br />
The main idea is expressed by the following points:<br />
<br />
* the system allows the specification of a set of tests<br />
** each test is a black box test<br />
*** each test contains a set of assertions<br />
*** each assertion checks both the execution order as well as return values of functions<br />
*** the test is successful when the test executed in the proper order<br />
<br />
* the tests are compiled for a target platform<br />
** for each test is possible to specify for which architecture it works (variable <tt>worksfor</tt> in <tt>conf.in</tt>)<br />
** for each test it is possible to specify a set of values for the testing<br />
*** typical example: a test must work for BCC1, BCC2, ECC1, ECC2, both standard and extended error checking<br />
*** the system will test all the possible combination of all the variables (in the case above, they will be 8 combinations)<br />
*** please refer the variable <tt>conf</tt> in <tt>conf.in</tt><br />
<br />
* the test generates a debugger configuration (e.g. for Lauterbach)<br />
** the debugger configuration is responsible to run all tests<br />
** each run does the following:<br />
*** loads the application<br />
*** sets a breakpoint in a specific position (typically <tt>EE_assert_last</tt><br />
*** runs the application<br />
*** if the application does not stop, then it is a failure :-)<br />
*** if the application stops, then a variable is tested. If it is ok, it means that all the execution of all the assertions are correct<br />
** all the debugger output is returned and stored in a log file.<br />
<br />
* the tests currently implement the [http://portal.osek-vdx.org/index.php?option=com_content&task=view&id=13&Itemid=16 MODISTARC tests], plus some other tests to check the behavior of the main context change and interrupt functions.<br />
<br />
= Important files =<br />
<br />
* all files are stored inside the <tt>testcase</tt> directory<br />
* the <tt>testcase/makefile</tt> if run without parameters gives an idea of the possible commands<br />
* each test is stored in a separate directory<br />
** conf.in which contains the settings that explains how to run the test<br />
*** note that the conf.in settings are handled as #defines in the OIL and.c file<br />
** code.c is the test source code<br />
** appl.oil is the OIL configuration file<br />
* common<br />
** contains all the scritps<br />
** important things to look at are the subdirectories, one for each architecture, and in particular the test.mk which contains information of the commands run at each phase.<br />
<br />
= More info =<br />
Some more information can be found at [[Running the MODISTARC regression tests]].<br />
<br />
For MPC5674F please refere to <tt> http://erika.tuxfamily.org/wiki/index.php?title=How_to_run_the_MODISTARC_regression_tests_for_Freescale_MPC5674F </tt></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Black_Box_Regression_testsBlack Box Regression tests2014-07-29T06:35:14Z<p>Francesco: /* More info */</p>
<hr />
<div>This page documents about the Black Box regression tests implemented for ERIKA Enterprise.<br />
<br />
= Main idea =<br />
The main idea is expressed by the following points:<br />
<br />
* the system allows the specification of a set of tests<br />
** each test is a black box test<br />
*** each test contains a set of assertions<br />
*** each assertion checks both the execution order as well as return values of functions<br />
*** the test is successful when the test executed in the proper order<br />
<br />
* the tests are compiled for a target platform<br />
** for each test is possible to specify for which architecture it works (variable <tt>worksfor</tt> in <tt>conf.in</tt>)<br />
** for each test it is possible to specify a set of values for the testing<br />
*** typical example: a test must work for BCC1, BCC2, ECC1, ECC2, both standard and extended error checking<br />
*** the system will test all the possible combination of all the variables (in the case above, they will be 8 combinations)<br />
*** please refer the variable <tt>conf</tt> in <tt>conf.in</tt><br />
<br />
* the test generates a debugger configuration (e.g. for Lauterbach)<br />
** the debugger configuration is responsible to run all tests<br />
** each run does the following:<br />
*** loads the application<br />
*** sets a breakpoint in a specific position (typically <tt>EE_assert_last</tt><br />
*** runs the application<br />
*** if the application does not stop, then it is a failure :-)<br />
*** if the application stops, then a variable is tested. If it is ok, it means that all the execution of all the assertions are correct<br />
** all the debugger output is returned and stored in a log file.<br />
<br />
* the tests currently implement the [http://portal.osek-vdx.org/index.php?option=com_content&task=view&id=13&Itemid=16 MODISTARC tests], plus some other tests to check the behavior of the main context change and interrupt functions.<br />
<br />
= Important files =<br />
<br />
* all files are stored inside the <tt>testcase</tt> directory<br />
* the <tt>testcase/makefile</tt> if run without parameters gives an idea of the possible commands<br />
* each test is stored in a separate directory<br />
** conf.in which contains the settings that explains how to run the test<br />
*** note that the conf.in settings are handled as #defines in the OIL and.c file<br />
** code.c is the test source code<br />
** appl.oil is the OIL configuration file<br />
* common<br />
** contains all the scritps<br />
** important things to look at are the subdirectories, one for each architecture, and in particular the test.mk which contains information of the commands run at each phase.<br />
<br />
= More info =<br />
Some more information can be found at [[Running the MODISTARC regression tests]].<br />
For MPC5674F please refere to <tt> http://erika.tuxfamily.org/wiki/index.php?title=How_to_run_the_MODISTARC_regression_tests_for_Freescale_MPC5674F </tt></div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=How_to_run_the_MODISTARC_regression_tests_for_Freescale_MPC5674FHow to run the MODISTARC regression tests for Freescale MPC5674F2014-07-29T06:24:32Z<p>Francesco: </p>
<hr />
<div># Checkout the svn repository to work with the last version of the test cases. Note that you can use subversion in anonymous mode without logging in (in this case you won't be allowed to write on the repository for adding, editing or removing files). <br />
#* To checkout the source, type: <tt> svn co svn://svn.tuxfamily.org/svnroot/erika/erikae/repos/ee/trunk/ee </tt><br />
#* To update the sources type: <tt> svn update </tt><br />
# Change the working directory to: <tt> repos/ee/trunk/ee/testcase </tt><br />
# Start the compilation by typing <tt>make ARCH=e200zx</tt> (see below for other targets) and by specifying MCU target, e.g: make ARCH=e200zx_diab_5_5_1_vle MCU_TARGET=mamba where mamba represents MPC5674F. The build system will compile all the projects through the following steps:<br />
## Creating all the temporary directories;<br />
## Processing the OIL configuration files using RT_DRUID;<br />
## Compiling the sources to generate the .elf files;<br />
## Creating the Lauterbach scripts to run the regression tests on the processor.DIRS="modistarc_task_1" </tt> <br />
# Launch the tests: <tt>cd tmp; t32mppc</tt><br />
# After the test, open the file <tt>tmp/report.log</tt>. You should find a line saying <tt>Test OK</tt> for every test; if a test is marked with <tt>Test Failed</tt> then you have found something broken.<br />
<br />
The <tt>e200zx</tt> target uses the Diab compiler and the FLE instruction set. It is possible to choose the CodeWarrior compiler and/or the VLE instruction set using one of these other targets: <tt>e200zx_diab_vle</tt>, <tt>e200zx_codewarrior_vle</tt>, or <tt>e200zx_codewarrior_fle</tt>.<br />
<br />
See also: [[Freescale PPC e200 (MPC 56xx)]]</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Freescale_PPC_e200_(MPC_56xx)Freescale PPC e200 (MPC 56xx)2014-07-18T13:30:41Z<p>Francesco: /* OIL file configuration */</p>
<hr />
<div>= Freescale PPC e200 (MPC 56xx) support =<br />
ERIKA Enterprise supports the PPC e200 family microcontrollers.<br />
The support for RT-Druid is available starting from release 1.5.0.<br />
The support includes: <br />
# Support MPC5674F (e200z7). MPC5668G (e200z6) is supported in version 1.6.0; version 1.6.1 will support both cores (z6 and z0) of the MPC5668G (already available on the [[ERIKA Enterprise and RT-Druid SVN Access|Subversion repository]]). Support for MPC5643L (e200z4).<br />
# Support for the WindRiver DIAB and Freescale CodeWarrior compilers.<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers<br />
** WindRiver DIAB C Compiler 5.5.1 and 5.8.0.<br />
** Freescale CodeWarrior:<br />
*** Windows: CodeWarrior Development Studio for MPC55xx/56xx 2.7<br />
*** Linux: CodeWarrior Development Studio for MCU 10.2<br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: Currently limited to the MPC5668G and MPC5643L, it follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ Autosar]: two instances of the operating systems run on the two cores, and communication between cores is performed with a few APIs and shared memory.<br />
<br />
* MMU Handling<br />
** Static global mappings to let all the application see all the memory/peripherals in the system; no memory protection is implemented and all the code is executed in supervisor mode.<br />
<br />
== Host Configuration ==<br />
<br />
* RT-Druid requires Java 1.6.<br />
* It is possible to use a version of ERIKA more recent than the one provided with RT-Druid; just download the ERIKA tree from the repository (see [[ERIKA Enterprise and RT-Druid SVN Access]]) and point the '''ERIKA_FILES''' environment variable to its location; see [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]] for some caveats.<br />
<br />
=== Wind River Diab ===<br />
* Compiler: The compiler commands (dcc, das, dld, and dar) are assumed to be reachable from the $PATH. If a specific version of them has to be used it must be specified in pkg/cfg/arch/cc_z7diab.mk<br />
* Operating system: The PPC e200 port has been developed under Debian testing/unstable as of May 2010; the only known requirement is Java 1.6 to run RT-Druid.<br />
* In the reference environment, the Diab toolchain was located in /opt/case/diabdata/<version> and Eclipse in /opt/eclipse. No hard requirement is made by the build system, as specified above. <br />
<br />
=== Freescale CodeWarrior ===<br />
*Compiler: The compiler directory can be specified using the environment variable '''PPC_CW_BASEDIR'''; this directory must contain the directories ''PA_Support'', and ''PA_Tools'' or ''PowerPC_EABI_Tools''. ERIKA makefiles find all the files they need with relatives paths from there. Please notice that makefiles require that the variable '''PPC_CW_BASEDIR''' do not contain any space. An evaluation or a limited version of the compiler can be downloaded from the [http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_DOWNLOADS Freescale Web site].<br />
*Operating system: both Linux and Windows are supported. CodeWarrior support has been developed under Debian Linux and Windows XP, but other (and more recent) versions should work. On Windows, ''Special Edition: CodeWarrior for Microcontrollers 10.5'' is currently used, and on Linux ''CodeWarrior Development Studio for MCU'' version 10.2. On Windows the Cygwin environment is used for ERIKA makefiles, so the '''PPC_CW_BASEDIR''' variable must use forward slashes '/' and must not contain spaces; you can always convert the path with the ''cygpath'' command. For example, in this case the value to use is <code>/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7</code>:<br />
$ cygpath.exe `cygpath.exe -ms "/c/Program Files/Freescale/CW for MPC55xx and MPC56xx 2.7"`<br />
/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7<br />
*OIL file: Currently, an ''EEOPT'' with value '''"__CODEWARRIOR__"''' must be specified in the OIL file. See [[#OIL file configuration]] for more details.<br />
<br />
== Target configuration and programming==<br />
<br />
* ERIKA is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]<br />
* ERIKA supports the Freescale MPC5674F, MPC5668G and MPC5643L MCUs (we have been able to run it on an MPC56XX and others; Freescale MCUs are really very similar).<br />
* At system boot the interrupt controller is set up to work in Software Vector Mode, and all the interrupts are associated to default handlers. The kernel does not use any specific device/interrupts, although for testing purposes it is possible to use the decrementer and some gpios as interrupt sources. All the code is executed from flash, all the data sections are loaded into the SRAM at boot time (the MMU is configured to provide 1:1 mappings for code running in system mode for all the sensible regions, like flash, sram and device registers).<br />
* The version in the repository supports both FLE and VLE modes.<br />
* The scripts generated by the build process are compatible with Lauterbach v200912. The commands generated to setup the NEXUS port are not compatible with older releases of the Lauterbach software. In case you hit this problem, remove the NEXUS.* lines from the generated scripts, ad set up the port according to the Lauterbach version you are using.<br />
* Target registers are used according the PPC ABI described in the DIAB manual.<br />
* The stack fill pattern is configurable at compile time, but is assumed to be 0xa5.<br />
* For Osek conformance classes, which support TerminateTask(), each running task requires 96 bytes of stack. <br />
For multistack configurations, 76 bytes are required on each stack for context switching. You can add this numbers to the requirements of your application to estimate task usage.<br />
* Stack pointer is aligned at 16 byte (fixed in version 1.6)<br />
<br />
=== MCUs ===<br />
* The MCUs supported are currently the following:<br />
** MPC5674F (Mamba)<br />
** MPC5668G (Fado)<br />
** MPC5643L (Leopard)<br />
<br />
===OIL file configuration===<br />
For more information about configuration through OIL file, see [[Tutorial: RT-Druid and OIL basics]]. Here only the e200zX-specific part of OIL is described.<br />
;CPU (CPU_DATA)<br />
: CPU must be set to E200ZX. The exact model is specified with the '''MODEL''' item (supported values are '''E200Z0''', '''E200Z6''' , '''E200Z7''' and '''E200Z4'''. Generation of VLE code can be selected by setting '''VLE''' to '''TRUE'''; please notice that all the application and the OS code must have the same setting, as ERIKA makefiles do not support mixed programs. Size in byte of the shared stack can be specified with the optional '''SYS_STACK_SIZE''' item.<br />
: Example of a CPU_DATA section:<br />
CPU_DATA = PPCE200ZX {<br />
ID = "MainCpu";<br />
MODEL = E200Z7;<br />
APP_SRC = "main.c";<br />
MULTI_STACK = FALSE;<br />
VLE = FALSE;<br />
SYS_STACK_SIZE = 512;<br />
};<br />
:On multicore systems, one CPU_DATA instance can exist for each core. They must have different '''ID'''s. See [[ERIKA multicore support]] for more details about multicore systems on Erika.<br />
;MCU<br />
: MCU support is present for MPC5674F ,MPC5668G and MPC5643L. The only item supported is '''MODEL''', which can be either '''MPC5674F''', '''MPC5668G''' or '''MPC5643L'''. Most of the differences produced by this setting affect memory map and Lauterbach scripts.<br />
: Example:<br />
MCU_DATA = PPCE200ZX {<br />
MODEL = MPC5674F;<br />
};<br />
;System Timer<br />
Erika on PowerPC has a system timer based on PowerPC Decrementer. This feature is available for all supported MCUs: MPC5674F (Mamba), MPC5668G(Fado) and MPC5643L (Leopard). System time also requires CPU_CLOCK field to be set on CPU_DATA, hence CPU_CLOCK value must be added in CPU_DATA configuration to have a system timer configured.<br />
This is an example to configure Decrementer as System Timer:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_DECREMENTER";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "DECREMENTER";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
<br />
Furthermore for MPC5643L (Leopard) is available a system timer based on Freescale STM (System Timer Module), that is a device available in several Freescale PowerPC MCUs. In this case the following configuration must be take into account:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_STM";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
...<br />
...<br />
<br />
<br />
;EEOPTs<br />
: See also [[EEOPT]] for common EEOPTs.<br />
: Special options for the PPC e200 ERIKA porting can be specified through '''EE_OPT''' items in the '''OS''' section (please notice that the value for an '''EE_OPT''' is a string, so double quotes (") must be added around the values in this list.<br />
:; EE_SYSTEM_TIMER_DEVICE_DECREMENTER (see system timer section above)<br />
:; EE_SYSTEM_TIMER_DEVICE_STM (available only for MPC5643L, see system timer section above)<br />
:;EE_ISR_DYNAMIC_TABLE<br />
::Used to enable dynamic ISR table support that let register ISR handlers at runtime calling <code>EE_e200z7_register_ISR</code>.<br />
:;__E200ZX_EXECUTE_FROM_RAM__<br />
:: When specified, a linker script is used that maps both code and data in the RAM space. Executables produced with this option can be used only together with a debugger that loads the program in memory. By default, code and constant data are mapped to Flash, data to RAM.<br />
:;__CODEWARRIOR__<br />
:: Invoke Freescale CodeWarrior compiler. See [[#Freescale CodeWarrior]] for information on how to configure the compiler. The default compiler is Wind River Diab; see [[#Wind River Diab]] for configuration.<br />
:;__USE_CUSTOM_LINKER_SCRIPT__<br />
:: Don't use the dafault linker script. Users can direct the linker to use their own linker script by setting the <code>LDFLAGS</code> variable. Example:<br />
OS EE {<br />
EE_OPT = "__USE_CUSTOM_LINKER_SCRIPT__";<br />
LDFLAGS = "../my_linker_script.ld";<br />
};<br />
:;__USE_CUSTOM_CRT0__<br />
:: Don't use Erika default crt0. Users can provide their own crt0 by adding source files in the usual way (APP_SRC in the OIL file).<br />
;;__MINIMAL_CC_OPTIONS__<br />
:: Enable only the compiler flags absolutely needed to compile Erika, so users can easily add their preferences in CFLAGS.<br />
;;__EE_USE_MMU__<br />
:: Enable the MMU support. The MMU can be configured by calling <code>EE_e200zx_mmu_setup()</code>. See the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> for more details. An example configuration can be found in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt>.<br />
;;__EE_CRT0_INIT_MMU__<br />
:: Initialize the MMU from the crt0. See <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt> for an example, and the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt>.<br />
;;EE_NO_LIBEE<br />
:: To not generete the kernel library '''libee.a''' but link all the objects files (kernel + application) directly in an elf file. This option is useful to try Erika with CodeWarrior compiler with an evaluation license, because the archiver is not enabled with this license.<br />
;;DEBUG<br />
:: On this architecture, enabling debug symbols does not inhibit optimization.<br />
;;MPC5643L_STD_SW_MMU_CONFIG"<br />
:: This EE_OPT is valid only for MPC5643L (Leopard) and provides a standard (and in most cases sufficient) MMU configuration. This option is useful expecially running your code from FLASH where Debugger does not initializes the MMU for you.<br />
;;EE_LAUTERBACH_DEMO_SIM<br />
:: This option is available only for Mamba (MPC5674F), for details please take a look at DEMO_ErikaSim in the directory of templates. It causes the generation of Lauterbach scripts to use with Lauterbach simulator.<br />
<br />
There are a few examples in the ERIKA code base that can be used as a starting point for new projects. Examples include also a makefile, which can be used to compile a project without a need of an IDE. The makefile runs RT-Druid non-interactively, and requires the environment variable '''RTDRUID_ECLIPSE_HOME''' to point to the Eclipse directory where RT-Druid is installed.<br />
<br />
Examples can be accessed as templates in RT-Druid (see [[How to create, compile and debug an application for Freescale MPC5674F]]), or directly in the source code: [http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/ examples/ppc/].<br />
<br />
In the first version of ERIKA and RT-Druid supporting e200zX, the only e200-specific setting in the OIL configuration file was the CPU_DATA value, which had to be set to '''MPC5674F''' instead of '''PPCE200ZX'''. This not supported any more.<br />
<br />
=== APIs ===<br />
* List of functions (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_irq.h?view=markup pkg/cpu/e200zx/inc/ee_irq.h]</tt> for prototypes and other details):<br />
** EE_e200z7_register_ISR(level, handler, priority): Associate <tt>handler</tt> to the IRQ <tt>level</tt>, with the given <tt>priority</tt> (available only if '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' is set).<br />
** EE_e200z7_setup_decrementer(delay): Configure the decrementer to raise an interrupt every <tt>delay</tt> cycles.<br />
** EE_e200z7_setup_decrementer_oneshot(delay): Configure the decrementer to raise an interrupt <tt>delay</tt> cycles after invocation.<br />
** EE_e200z7_stop_decrementer(): Stop the decrementer from generating interrupts.<br />
** EE_e200zx_setup_fixed_intv(bitpos): Enable the fixed-interval interrupt.<br />
** EE_e200zx_stop_fixed_intv(): Disable the fixed-interval interrupt.<br />
** EE_e200zx_mmu_setup(entries, count): MMU initialization.<br />
<br />
Note: notice that the *_e200z7_* is slightly misleading since it seem to refer only to e200z7 family, it is a legacy name convention when the only supported architecture by Erika was Z7. Currently even Z0, Z4 and Z6 are supported hence these functions can be used for such architectures, although it refers to *_e200z7_*.<br />
<br />
====Interrupts====<br />
<br />
There are two way to configure ISR. The standard way is the static way with OIL configuration (example):<br />
<br />
ISR DecrIsr {<br />
CATEGORY = 2;<br />
ENTRY = "DECREMENTER";<br />
};<br />
<br />
ISR FixedIntvIsr {<br />
CATEGORY = 2;<br />
ENTRY = "FIXED_INTV";<br />
HANDLER = "fixed_intv_handler";<br />
};<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
ENTRY = "0";<br />
};<br />
ISR IsrMedium {<br />
CATEGORY = 2;<br />
PRIORITY = 2;<br />
ENTRY = "1";<br />
};<br />
<br />
ISR IsrHigh {<br />
CATEGORY = ;<br />
PRIORITY = 3;<br />
ENTRY = "2";<br />
HANDLER = "isr_high_handler";<br />
};<br />
<br />
In static ISR table handling mode there's full support for both ISR1 and ISR2 for '''external interrupt'''. To register an handler you should use the suitable macro ('''ISR1''' or '''ISR2''') passing the value of '''HANDLER''' field or the '''ISR name''', in case the former is missing. The configuration field '''ENTRY''' declare the position of the handler inside the vector table (the example show three handlers that get the first three positions in vector, corrisponding to the first three software interrupt request). Priority field corripsond to interrupt priority value set to corrisponding Interrupt Controller Priority select registers ('''INTC.PSR[(ENTRY)] = PRIORITY'''), the values have to be inside [0..15] range.<br />
<br />
There is direct support for two cpu '''internal exceptions''', those generated by the time base facilities: decrementer and fixed interval timer ('''ENTRY = "DECREMENTER"''' and '''ENTRY = "FIXED_INTV"'''' respectively.). Support for Watch-Dog timer will be added. To register an handler for internal interrupt you have to use '''ISR1_INT''' or '''ISR2_INT''' (two different couple of macros are needed to issue EOI, End Of Interrupt, only for external interrupts). Priority field in configuration have no meaning for internal interrupts.<br />
<br />
You can register handler by code dinamically with with the <code>EE_e200z7_register_ISR()</code> described above. To enable dynamic ISR table support you must declare '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' configuration OIL file. The '''first 16 level''' of dynamic table are reserved for '''internal exceptions''' handlers, so you have to add this offset to the '''ENTRY''' value of the static approach to register an handler to the same interrupt source.<br />
<br />
ISRs (Interrupt Service Routines) are just void functions with no arguments. For external interrupts (IVOR4), the EOI (End Of Interrupt) is issued by ERIKA's handler; user ISRs need not bother about that.<br />
<br />
====Multicore support (MPC5668 and MPC5643L)====<br />
* Functions used for multicore support on MPC5668 (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5668/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5668/inc/ee_dual.h]</tt> for prototypes and other details):<br />
** EE_mpc5668_start_z0(f): Enable the z0 CPU.<br />
<br />
The same paradigm of multicore support available for MPC5668G, is also available for the MPC5643L, (for details see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5643l/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5643l/inc/ee_dual.h]</tt>). Likewise MPC5668G, in order to start the slave core, a EE_mpc5643l_start_slave(f) call has to be provided at startup (typically in main function) immediately before the StartOS().<br />
<br />
=== Boards ===<br />
* ERIKA has been developed on an '''Axiom MPC5674evbfxmb evaluation board'''. This evaluation board has the MAMBA microcontroller (Freescale MPC5674F)<br />
** The kernel has no dependency on the board itself, but some of its functionalities can be used for debugging purposes. Including file "pkg/board/axiom_mpc5674fxmb/inc/ee_board.h" the following functions can be used:<br />
*** EE_leds_init(): which sets up the GPIOs associated with the leds.<br />
*** EE_EE_leds(mask): which turns the i-th led on or off depending on the state of the i-th bit in the mask passed as an argument.<br />
*** EE_led_<X>_on()/EE_led_<X>_off(): turns led X on or off.<br />
*** EE_buttons_disable_interrupts(button): disables the interrupt associated to the given button.<br />
*** EE_buttons_enable_interrupts(button): enables it.<br />
*** EE_buttons_clear_ISRflag(button): acknowledges the interrupt coming from the given button.<br />
*** EE_button_get_B<X>(): gets the status of button X.<br />
*** EE_buttons_init(): initializes the GPIOs associated to buttons.<br />
** The functions above are available if, respectively, __USE_LEDS__ and __USE_BUTTONS__ are defined upon inclusion of ee_board.h<br />
** The connections are assumed to be the following:<br />
*** GPIO 147-150: connected to LED0-3. Looking at the pins on the EVB:<br />
**** ETPUB1 -> USER_LED1<br />
**** ETPUB2 -> USER_LED2<br />
**** ETPUB3 -> USER_LED3<br />
*** GPIO 450: connected to BUTTON0 (ETPUC9 -> USER_DEV1)<br />
<br />
* Erika is available for the '''Freescale MPC5668EVB Evaluation Board'''. This evaluation board has the FADO microcontroller (Freescale MPC5668G)<br />
** for this board the are no available support for leds or buttons.<br />
<br />
* Erika is available for '''Freescale MPC564xLEVB Evaluation Board'''. This evaluation board has the LEOPARD microcontroller (Freescale MPC5643L)<br />
** for this board there is the same set of primitives defined for "Axiom MPC5674evbfxmb" board, hence a basic support for leds and button is available.<br />
<br />
== Multicore support ==<br />
<br />
In the ERIKA multicore support for PPC e200 there are a few aspects specific to the PPC e200 architecture, and they are described here. Please refer to [[ERIKA multicore support]] for general information on ERIKA multicore systems.<br />
<br />
The PPC evaluation board supported by Erika Multicore is the Freescale MPC5668G/E Evaluation kit, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5668GKIT. The multicore support is also provided for MPC5643L with the Freescale evaluation board MPC564xL EVB, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=XKT564L.<br />
<br />
In multicore configuration, is it possible running both instances of the operating system both in RAM and Flash. For instance on MPC5668G, the internal SRAM is partitioned statically in two: memory from 0x40000000 to 0x4001FFFF is reserved to the first core and shared variables, while memory from 0x40020000 to 0x4003FFFF is reserved to the second core. 0x40020000 is used as the starting address of the second core. A similar approach is available for MPC5643L. In order to customize such memory assignments please refer to memory0.ld and memory1.ld files in "erika/pkg/mcu/freescale_mpc56XX/cfg/multicore" (where XX=43l for Leopard and XX=68 for Fado).<br />
<br />
Shared variable data is allocated in a single section (<tt>.mcglobald</tt>). Access to this section must be performed without cache, or the OS may malfunction. ERIKA crt0 does not enable cache; if you want to enable it, you should also make sure that the <tt>.mcglobald</tt> section is allocated on a page on its own by the linker script, and that the MMU is configured to mark such page as non-cached. <br />
<br />
The OS uses two software interrupts (6 and 7) and two hardware semaphores (0 and 1) of the MPC5668G to handle inter-core communication. They are initialised inside <code>StartOS()</code>. While all the other software interrupts and semaphores are available for user applications, those used by the OS should not be meddled with by user code. It is okay to briefly mask the interrupts with higher-priority interrupts or by disabling interrupts. In case of MPC5643L, as the microcontroller has two different interrupt controllers (one for each core), SW interrupt number 7 is used for both cores. Even if the MPC5643L has two SEMA4 modules, only the first module (the one associated to the master core) is used for this mechanism, this means that semaphores 0 and 1 of the first SEMA4 module are used for synchronisation (as in MPC5668G), while the remaining semaphores of the first SEMA4 module and all semaphores belonging to the second SEMA4 module are available for user applications.<br />
<br />
Examples of multicore applications are in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/ examples/ppc/dual_examples]</tt>. In particular, <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/mono_activate01/ examples/ppc/dual_examples/mono_activate01]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/multi_event01/ examples/ppc/dual_examples/multi_event01]</tt> are complete applications, nearer to real-world usage.<br />
<br />
Erika multicore for PowerPC supports AUTOSAR OS-like functionalities. For details please see the following page (but take into account that these features have not been published yet):<br />
[[Erika AUTOSAR OS]]<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for PPC e200 produces a Lauterbach Trace32 configuration file (<tt>t32.cmm</tt>) and a ORTI description file (<tt>system.orti</tt>) inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger, please issue <code>t32mppc</code> from the output directory. The ERIKA build system honors the <tt>T32SYS</tt> environment variable, if set.<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named <tt>start.sh</tt>) is produced in the output directory. To run the debugger, please issue <code>start.sh</code> from the output directory. The script creates two instances of the debugger, one for each core. For instace when MPC5668G is turned on, only the first (Z6) core is enabled. In order to simulate the real setup, the debugger connected to the second (Z0) core does not enable its core, but it is responsibility of the code running on the Z6 core to enable the Z0 core (this is different from the example script for MPC5668G distributed with the Lauterbach Trace32 software). Nonetheless, the startup script loads all the code and the debug symbols for both core and both debugger instances. In a typical debugging session, you start the execution of the code on the Z6 core from its debugger, and then, when the Z0 core has become active, start also the code on the Z0 core from the Z0 debugger. The barrier inside <code>StartOS()</code> comes handy to synchronize the code running on the two cores. The <tt>start.sh</tt> script runs only on Linux; currently the ERIKA build system does not support Windows to run Trace32 for e200 multicore systems. A similar approach has been adopted for MPC5643L.<br />
<br />
==Internals==<br />
<br />
===Interrupts===<br />
<br />
Interrupt handling in PPC e200 ERIKA uses software vector mode and a single entry point for all interrupts and exceptions, which is <code>EE_e200z7_irq()</code>. This function calls the user ISR and issues the end-of-interrupt for external interrupts; when the served interrupt is not nested, i.e., it interrupted a task directly, <code>EE_e200z7_irq()</code> also calls the scheduler before returning.<br />
<br />
This scheme of IRQ handling can be changed by rewriting the crt0 and changing the IVOR setup. In this way it is possible, for example, to use hardware vector mode. Please note that it is important that the end-of-interrupt be issued before calling the scheduler, as the scheduler may not return when a new task is to be scheduled.<br />
<br />
===Use of non volatile registers in Erika PowerPC===<br />
<br />
Some Erika RTOS assembly modules in PowerPC use non volatile registers for their internal purposes (r14-r31). Such modules are:<br />
<br />
* ee_e200zx_contex.S - This module is in charge of managing context switch for multistack on e200zx. In this module r14-r31 are saved and restored in a prologue and epilogue;<br />
* ee_oo.S - This module is in charge of saving and restoring registers for Osek TerminateTask() on e200zx. In this module r14-r31 are saved and restored in a prologue and epilogue;<br />
* ee_entry.S - This module handles exception entry points and hardware setup for the e200zx. In this module the istruction stmw uses r28-r30 to initialize SRAM. This code is stripped if a custom ISR table is used (see EE_ISR_EXTERNAL_TABLE for details);<br />
* ee_boot.S - This module represents boot sequence for PowerPC MCUs. The erika boot sequence accesses non volatile registers in init phase. This code can be removed from build process (see __USE_CUSTOM_CRT0__ for details).<br />
<br />
The use of r14-r31 registers is limited, just few lines of code. But this information is relevant in case advanced features of some compilers are used, (e.g.: to define additional non-standard SDAs, Small Data Area). For instance Windriver Diab compiler has the REGISTER directive in the linker script to fullfill this requirement. If this non-standard approach is not required this information can be neglected. It is provided in order to give the position of such code whenever the use of non volatile registers (r14-r31) is necessary for non-standard purposes. For details please refere to your compiler documentation.<br />
<br />
'''Assumption for future development:''' additional SDA base addresses will be stored starting from register r14<br />
<br />
== Download and install of Eclipse, RT-Druid, and ERIKA source ==<br />
<br />
To build an ERIKA application you need:<br />
* ERIKA source code<br />
* RT-Druid and a hosting Eclipse<br />
* Some command-line tools<br />
<br />
=== ERIKA source code ===<br />
<br />
ERIKA source code is bundled with RT-Druid. ERIKA for PPC e200 honors the definition of '''ERIKA_FILES''', so you can use the latest version of ERIKA as explained in [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]].<br />
<br />
=== Eclipse and RT-Druid in one piece ===<br />
<br />
A complete version of an Eclipse installation together with the RT-Druid plugin can be downloaded from this page:<br />
http://erika.tuxfamily.org/erika-for-multiple-devices.html. Please make sure to use a version not older than 1.6.0 beta. See also [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application]].<br />
<br />
=== Eclipse and RT-Druid piece by piece ===<br />
<br />
Alternatively, if you already have a copy of Eclipse or you want to use a version of Eclipse different from the one provided by the page above, you can follow this procedure.<br />
* To download the e200 plug-in for Eclipse refer the following site: [http://download.tuxfamily.org/erika/webdownload/rtdruid_beta Plug-in download site].<br />
Procedure for installation:<br />
* Step 0:<br />
: Get ''Eclipse'' and required plug-ins;<br />
: Where possible, the suggestion is to download the ''all in one update site'' and use the eclipse update manager or to use the eclipse update manager directly on a web site;<br />
:* Eclipse<br />
:: If you don't have any eclipse installations, you can download eclipse with cdt already installed from [http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/heliossr1 Eclipse IDE for C/C++].<br />
:: It is also possible use an already installed distribution of eclipse or to download one (for example from [http://www.eclipse.org/downloads Eclipse Downloads]) and then add all missing plug-ins.<br />
:* EMF<br />
:: The main page to download EMF is [http://www.eclipse.org/modeling/emf/downloads/?project=emf Eclipse Modeling Framework].<br />
:: The version to download is related to the eclipse version: eclipse 3.3 -> emf 2.3 , eclipse 3.4 -> emf 2.4, eclipse 3.5 -> emf 2.5, eclipse 3.6 -> emf 2.6. <br />
:: The list of required plugins is:<br />
::: org.eclipse.emf.common<br />
::: org.eclipse.emf.ecore<br />
::: org.eclipse.emf.edit<br />
::: org.eclipse.emf.common.ui<br />
::: org.eclipse.emf.edit.ui<br />
:: Clearly it is possible to install more plugins, like the whole emf runtime or sdk<br />
:* CDT<br />
:: The main page to download CDT is [http://www.eclipse.org/cdt/downloads.php CDT Downloads].<br />
:: Also here, the version to download is related to eclipse version. <br />
:: In this case is required only the cdt runtime plugin.<br />
: [http://erika.tuxfamily.org/forum/viewtopic.php?f=6&t=651&sid=89784e2d97765c3f1c41f6e3c049437a#p727 Forum Post (in italian) about installing the Eclipse plugins]<br />
* Step 1:<br />
: Open ''Eclipse'';<br />
: From the menu ''Help'' select ''Install New Software...'';<br />
: Add with the button ''Add...'' the reference site mentioned above (fill the Location field with this: http://download.tuxfamily.org/erika/webdownload/rtdruid_beta);<br />
: Tick all plug-ins related to RT-Druid core and to Erika Enterprise, then click on the button ''Next'' to install them;<br />
: Restart Eclipse;<br />
* Step 2:<br />
: From the menu ''File'' select ''New'' and then RT-Druid Oil and C/C++ Project;<br />
: From the Project menu select one of the available e200 demo tests;<br />
: Then click on the project name with the right mouse button and build to obtain the elf object module for debugging;<br />
<br />
=== Additional software ===<br />
<br />
ERIKA uses GNU make and some command-line utilities to build programs. You need the following tools (please notice that only the less common commands are listed here; very common commands that are present in any Unix/POSIX system like ''ls'' are not listed for simplicity):<br />
* make (GNU version)<br />
* gawk (GNU AWK)<br />
* sed<br />
* grep<br />
<br />
For Linux the above commands are present in virtually every standard installation; but you can always install them from the respective packages of your distributions.<br />
<br />
For Windows, [http://www.cygwin.com/ Cygwin] is recommended. Please make sure to include the above packages (package names are the same as the tool names).<br />
<br />
== HOWTOs ==<br />
* [[How to create, compile and debug an application for Freescale MPC5674F]]<br />
* [[How to run the MODISTARC regression tests for Freescale MPC5674F]]<br />
<br />
<br />
[[Category:Supported Devices]]</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Freescale_PPC_e200_(MPC_56xx)Freescale PPC e200 (MPC 56xx)2014-07-18T13:29:35Z<p>Francesco: /* OIL file configuration */</p>
<hr />
<div>= Freescale PPC e200 (MPC 56xx) support =<br />
ERIKA Enterprise supports the PPC e200 family microcontrollers.<br />
The support for RT-Druid is available starting from release 1.5.0.<br />
The support includes: <br />
# Support MPC5674F (e200z7). MPC5668G (e200z6) is supported in version 1.6.0; version 1.6.1 will support both cores (z6 and z0) of the MPC5668G (already available on the [[ERIKA Enterprise and RT-Druid SVN Access|Subversion repository]]). Support for MPC5643L (e200z4).<br />
# Support for the WindRiver DIAB and Freescale CodeWarrior compilers.<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers<br />
** WindRiver DIAB C Compiler 5.5.1 and 5.8.0.<br />
** Freescale CodeWarrior:<br />
*** Windows: CodeWarrior Development Studio for MPC55xx/56xx 2.7<br />
*** Linux: CodeWarrior Development Studio for MCU 10.2<br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: Currently limited to the MPC5668G and MPC5643L, it follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ Autosar]: two instances of the operating systems run on the two cores, and communication between cores is performed with a few APIs and shared memory.<br />
<br />
* MMU Handling<br />
** Static global mappings to let all the application see all the memory/peripherals in the system; no memory protection is implemented and all the code is executed in supervisor mode.<br />
<br />
== Host Configuration ==<br />
<br />
* RT-Druid requires Java 1.6.<br />
* It is possible to use a version of ERIKA more recent than the one provided with RT-Druid; just download the ERIKA tree from the repository (see [[ERIKA Enterprise and RT-Druid SVN Access]]) and point the '''ERIKA_FILES''' environment variable to its location; see [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]] for some caveats.<br />
<br />
=== Wind River Diab ===<br />
* Compiler: The compiler commands (dcc, das, dld, and dar) are assumed to be reachable from the $PATH. If a specific version of them has to be used it must be specified in pkg/cfg/arch/cc_z7diab.mk<br />
* Operating system: The PPC e200 port has been developed under Debian testing/unstable as of May 2010; the only known requirement is Java 1.6 to run RT-Druid.<br />
* In the reference environment, the Diab toolchain was located in /opt/case/diabdata/<version> and Eclipse in /opt/eclipse. No hard requirement is made by the build system, as specified above. <br />
<br />
=== Freescale CodeWarrior ===<br />
*Compiler: The compiler directory can be specified using the environment variable '''PPC_CW_BASEDIR'''; this directory must contain the directories ''PA_Support'', and ''PA_Tools'' or ''PowerPC_EABI_Tools''. ERIKA makefiles find all the files they need with relatives paths from there. Please notice that makefiles require that the variable '''PPC_CW_BASEDIR''' do not contain any space. An evaluation or a limited version of the compiler can be downloaded from the [http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_DOWNLOADS Freescale Web site].<br />
*Operating system: both Linux and Windows are supported. CodeWarrior support has been developed under Debian Linux and Windows XP, but other (and more recent) versions should work. On Windows, ''Special Edition: CodeWarrior for Microcontrollers 10.5'' is currently used, and on Linux ''CodeWarrior Development Studio for MCU'' version 10.2. On Windows the Cygwin environment is used for ERIKA makefiles, so the '''PPC_CW_BASEDIR''' variable must use forward slashes '/' and must not contain spaces; you can always convert the path with the ''cygpath'' command. For example, in this case the value to use is <code>/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7</code>:<br />
$ cygpath.exe `cygpath.exe -ms "/c/Program Files/Freescale/CW for MPC55xx and MPC56xx 2.7"`<br />
/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7<br />
*OIL file: Currently, an ''EEOPT'' with value '''"__CODEWARRIOR__"''' must be specified in the OIL file. See [[#OIL file configuration]] for more details.<br />
<br />
== Target configuration and programming==<br />
<br />
* ERIKA is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]<br />
* ERIKA supports the Freescale MPC5674F, MPC5668G and MPC5643L MCUs (we have been able to run it on an MPC56XX and others; Freescale MCUs are really very similar).<br />
* At system boot the interrupt controller is set up to work in Software Vector Mode, and all the interrupts are associated to default handlers. The kernel does not use any specific device/interrupts, although for testing purposes it is possible to use the decrementer and some gpios as interrupt sources. All the code is executed from flash, all the data sections are loaded into the SRAM at boot time (the MMU is configured to provide 1:1 mappings for code running in system mode for all the sensible regions, like flash, sram and device registers).<br />
* The version in the repository supports both FLE and VLE modes.<br />
* The scripts generated by the build process are compatible with Lauterbach v200912. The commands generated to setup the NEXUS port are not compatible with older releases of the Lauterbach software. In case you hit this problem, remove the NEXUS.* lines from the generated scripts, ad set up the port according to the Lauterbach version you are using.<br />
* Target registers are used according the PPC ABI described in the DIAB manual.<br />
* The stack fill pattern is configurable at compile time, but is assumed to be 0xa5.<br />
* For Osek conformance classes, which support TerminateTask(), each running task requires 96 bytes of stack. <br />
For multistack configurations, 76 bytes are required on each stack for context switching. You can add this numbers to the requirements of your application to estimate task usage.<br />
* Stack pointer is aligned at 16 byte (fixed in version 1.6)<br />
<br />
=== MCUs ===<br />
* The MCUs supported are currently the following:<br />
** MPC5674F (Mamba)<br />
** MPC5668G (Fado)<br />
** MPC5643L (Leopard)<br />
<br />
===OIL file configuration===<br />
For more information about configuration through OIL file, see [[Tutorial: RT-Druid and OIL basics]]. Here only the e200zX-specific part of OIL is described.<br />
;CPU (CPU_DATA)<br />
: CPU must be set to E200ZX. The exact model is specified with the '''MODEL''' item (supported values are '''E200Z0''', '''E200Z6''' , '''E200Z7''' and '''E200Z4'''. Generation of VLE code can be selected by setting '''VLE''' to '''TRUE'''; please notice that all the application and the OS code must have the same setting, as ERIKA makefiles do not support mixed programs. Size in byte of the shared stack can be specified with the optional '''SYS_STACK_SIZE''' item.<br />
: Example of a CPU_DATA section:<br />
CPU_DATA = PPCE200ZX {<br />
ID = "MainCpu";<br />
MODEL = E200Z7;<br />
APP_SRC = "main.c";<br />
MULTI_STACK = FALSE;<br />
VLE = FALSE;<br />
SYS_STACK_SIZE = 512;<br />
};<br />
:On multicore systems, one CPU_DATA instance can exist for each core. They must have different '''ID'''s. See [[ERIKA multicore support]] for more details about multicore systems on Erika.<br />
;MCU<br />
: MCU support is present for MPC5674F ,MPC5668G and MPC5643L. The only item supported is '''MODEL''', which can be either '''MPC5674F''', '''MPC5668G''' or '''MPC5643L'''. Most of the differences produced by this setting affect memory map and Lauterbach scripts.<br />
: Example:<br />
MCU_DATA = PPCE200ZX {<br />
MODEL = MPC5674F;<br />
};<br />
;System Timer<br />
Erika on PowerPC has a system timer based on PowerPC Decrementer. This feature is available for all supported MCUs: MPC5674F (Mamba), MPC5668G(Fado) and MPC5643L (Leopard). System time also requires CPU_CLOCK field to be set on CPU_DATA, hence CPU_CLOCK value must be added in CPU_DATA configuration to have a system timer configured.<br />
This is an example to configure Decrementer as System Timer:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_DECREMENTER";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "DECREMENTER";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
<br />
Furthermore for MPC5643L (Leopard) is available a system timer based on Freescale STM (System Timer Module), that is a device available in several Freescale PowerPC MCUs. In this case the following configuration must be take into account:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_STM";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
...<br />
...<br />
<br />
<br />
;EEOPTs<br />
: See also [[EEOPT]] for common EEOPTs.<br />
: Special options for the PPC e200 ERIKA porting can be specified through '''EE_OPT''' items in the '''OS''' section (please notice that the value for an '''EE_OPT''' is a string, so double quotes (") must be added around the values in this list.<br />
:; EE_SYSTEM_TIMER_DEVICE_DECREMENTER (see system timer section above)<br />
:; EE_SYSTEM_TIMER_DEVICE_STM (available only for MPC5643L, see system timer section above)<br />
:;EE_ISR_DYNAMIC_TABLE<br />
::Used to enable dynamic ISR table support that let register ISR handlers at runtime calling <code>EE_e200z7_register_ISR</code>.<br />
:;__E200ZX_EXECUTE_FROM_RAM__<br />
:: When specified, a linker script is used that maps both code and data in the RAM space. Executables produced with this option can be used only together with a debugger that loads the program in memory. By default, code and constant data are mapped to Flash, data to RAM.<br />
:;__CODEWARRIOR__<br />
:: Invoke Freescale CodeWarrior compiler. See [[#Freescale CodeWarrior]] for information on how to configure the compiler. The default compiler is Wind River Diab; see [[#Wind River Diab]] for configuration.<br />
:;__USE_CUSTOM_LINKER_SCRIPT__<br />
:: Don't use the dafault linker script. Users can direct the linker to use their own linker script by setting the <code>LDFLAGS</code> variable. Example:<br />
OS EE {<br />
EE_OPT = "__USE_CUSTOM_LINKER_SCRIPT__";<br />
LDFLAGS = "../my_linker_script.ld";<br />
};<br />
:;__USE_CUSTOM_CRT0__<br />
:: Don't use Erika default crt0. Users can provide their own crt0 by adding source files in the usual way (APP_SRC in the OIL file).<br />
;;EE_ISR_EXTERNAL_TABLE<br />
:: Don't use Erika static ISR table. Users can provide their own ISR table.<br />
;;__MINIMAL_CC_OPTIONS__<br />
:: Enable only the compiler flags absolutely needed to compile Erika, so users can easily add their preferences in CFLAGS.<br />
;;__EE_USE_MMU__<br />
:: Enable the MMU support. The MMU can be configured by calling <code>EE_e200zx_mmu_setup()</code>. See the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> for more details. An example configuration can be found in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt>.<br />
;;__EE_CRT0_INIT_MMU__<br />
:: Initialize the MMU from the crt0. See <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt> for an example, and the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt>.<br />
;;EE_NO_LIBEE<br />
:: To not generete the kernel library '''libee.a''' but link all the objects files (kernel + application) directly in an elf file. This option is useful to try Erika with CodeWarrior compiler with an evaluation license, because the archiver is not enabled with this license.<br />
;;DEBUG<br />
:: On this architecture, enabling debug symbols does not inhibit optimization.<br />
;;MPC5643L_STD_SW_MMU_CONFIG"<br />
:: This EE_OPT is valid only for MPC5643L (Leopard) and provides a standard (and in most cases sufficient) MMU configuration. This option is useful expecially running your code from FLASH where Debugger does not initializes the MMU for you.<br />
;;EE_LAUTERBACH_DEMO_SIM<br />
:: This option is available only for Mamba (MPC5674F), for details please take a look at DEMO_ErikaSim in the directory of templates. It causes the generation of Lauterbach scripts to use with Lauterbach simulator.<br />
<br />
There are a few examples in the ERIKA code base that can be used as a starting point for new projects. Examples include also a makefile, which can be used to compile a project without a need of an IDE. The makefile runs RT-Druid non-interactively, and requires the environment variable '''RTDRUID_ECLIPSE_HOME''' to point to the Eclipse directory where RT-Druid is installed.<br />
<br />
Examples can be accessed as templates in RT-Druid (see [[How to create, compile and debug an application for Freescale MPC5674F]]), or directly in the source code: [http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/ examples/ppc/].<br />
<br />
In the first version of ERIKA and RT-Druid supporting e200zX, the only e200-specific setting in the OIL configuration file was the CPU_DATA value, which had to be set to '''MPC5674F''' instead of '''PPCE200ZX'''. This not supported any more.<br />
<br />
=== APIs ===<br />
* List of functions (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_irq.h?view=markup pkg/cpu/e200zx/inc/ee_irq.h]</tt> for prototypes and other details):<br />
** EE_e200z7_register_ISR(level, handler, priority): Associate <tt>handler</tt> to the IRQ <tt>level</tt>, with the given <tt>priority</tt> (available only if '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' is set).<br />
** EE_e200z7_setup_decrementer(delay): Configure the decrementer to raise an interrupt every <tt>delay</tt> cycles.<br />
** EE_e200z7_setup_decrementer_oneshot(delay): Configure the decrementer to raise an interrupt <tt>delay</tt> cycles after invocation.<br />
** EE_e200z7_stop_decrementer(): Stop the decrementer from generating interrupts.<br />
** EE_e200zx_setup_fixed_intv(bitpos): Enable the fixed-interval interrupt.<br />
** EE_e200zx_stop_fixed_intv(): Disable the fixed-interval interrupt.<br />
** EE_e200zx_mmu_setup(entries, count): MMU initialization.<br />
<br />
Note: notice that the *_e200z7_* is slightly misleading since it seem to refer only to e200z7 family, it is a legacy name convention when the only supported architecture by Erika was Z7. Currently even Z0, Z4 and Z6 are supported hence these functions can be used for such architectures, although it refers to *_e200z7_*.<br />
<br />
====Interrupts====<br />
<br />
There are two way to configure ISR. The standard way is the static way with OIL configuration (example):<br />
<br />
ISR DecrIsr {<br />
CATEGORY = 2;<br />
ENTRY = "DECREMENTER";<br />
};<br />
<br />
ISR FixedIntvIsr {<br />
CATEGORY = 2;<br />
ENTRY = "FIXED_INTV";<br />
HANDLER = "fixed_intv_handler";<br />
};<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
ENTRY = "0";<br />
};<br />
ISR IsrMedium {<br />
CATEGORY = 2;<br />
PRIORITY = 2;<br />
ENTRY = "1";<br />
};<br />
<br />
ISR IsrHigh {<br />
CATEGORY = ;<br />
PRIORITY = 3;<br />
ENTRY = "2";<br />
HANDLER = "isr_high_handler";<br />
};<br />
<br />
In static ISR table handling mode there's full support for both ISR1 and ISR2 for '''external interrupt'''. To register an handler you should use the suitable macro ('''ISR1''' or '''ISR2''') passing the value of '''HANDLER''' field or the '''ISR name''', in case the former is missing. The configuration field '''ENTRY''' declare the position of the handler inside the vector table (the example show three handlers that get the first three positions in vector, corrisponding to the first three software interrupt request). Priority field corripsond to interrupt priority value set to corrisponding Interrupt Controller Priority select registers ('''INTC.PSR[(ENTRY)] = PRIORITY'''), the values have to be inside [0..15] range.<br />
<br />
There is direct support for two cpu '''internal exceptions''', those generated by the time base facilities: decrementer and fixed interval timer ('''ENTRY = "DECREMENTER"''' and '''ENTRY = "FIXED_INTV"'''' respectively.). Support for Watch-Dog timer will be added. To register an handler for internal interrupt you have to use '''ISR1_INT''' or '''ISR2_INT''' (two different couple of macros are needed to issue EOI, End Of Interrupt, only for external interrupts). Priority field in configuration have no meaning for internal interrupts.<br />
<br />
You can register handler by code dinamically with with the <code>EE_e200z7_register_ISR()</code> described above. To enable dynamic ISR table support you must declare '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' configuration OIL file. The '''first 16 level''' of dynamic table are reserved for '''internal exceptions''' handlers, so you have to add this offset to the '''ENTRY''' value of the static approach to register an handler to the same interrupt source.<br />
<br />
ISRs (Interrupt Service Routines) are just void functions with no arguments. For external interrupts (IVOR4), the EOI (End Of Interrupt) is issued by ERIKA's handler; user ISRs need not bother about that.<br />
<br />
====Multicore support (MPC5668 and MPC5643L)====<br />
* Functions used for multicore support on MPC5668 (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5668/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5668/inc/ee_dual.h]</tt> for prototypes and other details):<br />
** EE_mpc5668_start_z0(f): Enable the z0 CPU.<br />
<br />
The same paradigm of multicore support available for MPC5668G, is also available for the MPC5643L, (for details see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5643l/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5643l/inc/ee_dual.h]</tt>). Likewise MPC5668G, in order to start the slave core, a EE_mpc5643l_start_slave(f) call has to be provided at startup (typically in main function) immediately before the StartOS().<br />
<br />
=== Boards ===<br />
* ERIKA has been developed on an '''Axiom MPC5674evbfxmb evaluation board'''. This evaluation board has the MAMBA microcontroller (Freescale MPC5674F)<br />
** The kernel has no dependency on the board itself, but some of its functionalities can be used for debugging purposes. Including file "pkg/board/axiom_mpc5674fxmb/inc/ee_board.h" the following functions can be used:<br />
*** EE_leds_init(): which sets up the GPIOs associated with the leds.<br />
*** EE_EE_leds(mask): which turns the i-th led on or off depending on the state of the i-th bit in the mask passed as an argument.<br />
*** EE_led_<X>_on()/EE_led_<X>_off(): turns led X on or off.<br />
*** EE_buttons_disable_interrupts(button): disables the interrupt associated to the given button.<br />
*** EE_buttons_enable_interrupts(button): enables it.<br />
*** EE_buttons_clear_ISRflag(button): acknowledges the interrupt coming from the given button.<br />
*** EE_button_get_B<X>(): gets the status of button X.<br />
*** EE_buttons_init(): initializes the GPIOs associated to buttons.<br />
** The functions above are available if, respectively, __USE_LEDS__ and __USE_BUTTONS__ are defined upon inclusion of ee_board.h<br />
** The connections are assumed to be the following:<br />
*** GPIO 147-150: connected to LED0-3. Looking at the pins on the EVB:<br />
**** ETPUB1 -> USER_LED1<br />
**** ETPUB2 -> USER_LED2<br />
**** ETPUB3 -> USER_LED3<br />
*** GPIO 450: connected to BUTTON0 (ETPUC9 -> USER_DEV1)<br />
<br />
* Erika is available for the '''Freescale MPC5668EVB Evaluation Board'''. This evaluation board has the FADO microcontroller (Freescale MPC5668G)<br />
** for this board the are no available support for leds or buttons.<br />
<br />
* Erika is available for '''Freescale MPC564xLEVB Evaluation Board'''. This evaluation board has the LEOPARD microcontroller (Freescale MPC5643L)<br />
** for this board there is the same set of primitives defined for "Axiom MPC5674evbfxmb" board, hence a basic support for leds and button is available.<br />
<br />
== Multicore support ==<br />
<br />
In the ERIKA multicore support for PPC e200 there are a few aspects specific to the PPC e200 architecture, and they are described here. Please refer to [[ERIKA multicore support]] for general information on ERIKA multicore systems.<br />
<br />
The PPC evaluation board supported by Erika Multicore is the Freescale MPC5668G/E Evaluation kit, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5668GKIT. The multicore support is also provided for MPC5643L with the Freescale evaluation board MPC564xL EVB, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=XKT564L.<br />
<br />
In multicore configuration, is it possible running both instances of the operating system both in RAM and Flash. For instance on MPC5668G, the internal SRAM is partitioned statically in two: memory from 0x40000000 to 0x4001FFFF is reserved to the first core and shared variables, while memory from 0x40020000 to 0x4003FFFF is reserved to the second core. 0x40020000 is used as the starting address of the second core. A similar approach is available for MPC5643L. In order to customize such memory assignments please refer to memory0.ld and memory1.ld files in "erika/pkg/mcu/freescale_mpc56XX/cfg/multicore" (where XX=43l for Leopard and XX=68 for Fado).<br />
<br />
Shared variable data is allocated in a single section (<tt>.mcglobald</tt>). Access to this section must be performed without cache, or the OS may malfunction. ERIKA crt0 does not enable cache; if you want to enable it, you should also make sure that the <tt>.mcglobald</tt> section is allocated on a page on its own by the linker script, and that the MMU is configured to mark such page as non-cached. <br />
<br />
The OS uses two software interrupts (6 and 7) and two hardware semaphores (0 and 1) of the MPC5668G to handle inter-core communication. They are initialised inside <code>StartOS()</code>. While all the other software interrupts and semaphores are available for user applications, those used by the OS should not be meddled with by user code. It is okay to briefly mask the interrupts with higher-priority interrupts or by disabling interrupts. In case of MPC5643L, as the microcontroller has two different interrupt controllers (one for each core), SW interrupt number 7 is used for both cores. Even if the MPC5643L has two SEMA4 modules, only the first module (the one associated to the master core) is used for this mechanism, this means that semaphores 0 and 1 of the first SEMA4 module are used for synchronisation (as in MPC5668G), while the remaining semaphores of the first SEMA4 module and all semaphores belonging to the second SEMA4 module are available for user applications.<br />
<br />
Examples of multicore applications are in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/ examples/ppc/dual_examples]</tt>. In particular, <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/mono_activate01/ examples/ppc/dual_examples/mono_activate01]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/multi_event01/ examples/ppc/dual_examples/multi_event01]</tt> are complete applications, nearer to real-world usage.<br />
<br />
Erika multicore for PowerPC supports AUTOSAR OS-like functionalities. For details please see the following page (but take into account that these features have not been published yet):<br />
[[Erika AUTOSAR OS]]<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for PPC e200 produces a Lauterbach Trace32 configuration file (<tt>t32.cmm</tt>) and a ORTI description file (<tt>system.orti</tt>) inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger, please issue <code>t32mppc</code> from the output directory. The ERIKA build system honors the <tt>T32SYS</tt> environment variable, if set.<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named <tt>start.sh</tt>) is produced in the output directory. To run the debugger, please issue <code>start.sh</code> from the output directory. The script creates two instances of the debugger, one for each core. For instace when MPC5668G is turned on, only the first (Z6) core is enabled. In order to simulate the real setup, the debugger connected to the second (Z0) core does not enable its core, but it is responsibility of the code running on the Z6 core to enable the Z0 core (this is different from the example script for MPC5668G distributed with the Lauterbach Trace32 software). Nonetheless, the startup script loads all the code and the debug symbols for both core and both debugger instances. In a typical debugging session, you start the execution of the code on the Z6 core from its debugger, and then, when the Z0 core has become active, start also the code on the Z0 core from the Z0 debugger. The barrier inside <code>StartOS()</code> comes handy to synchronize the code running on the two cores. The <tt>start.sh</tt> script runs only on Linux; currently the ERIKA build system does not support Windows to run Trace32 for e200 multicore systems. A similar approach has been adopted for MPC5643L.<br />
<br />
==Internals==<br />
<br />
===Interrupts===<br />
<br />
Interrupt handling in PPC e200 ERIKA uses software vector mode and a single entry point for all interrupts and exceptions, which is <code>EE_e200z7_irq()</code>. This function calls the user ISR and issues the end-of-interrupt for external interrupts; when the served interrupt is not nested, i.e., it interrupted a task directly, <code>EE_e200z7_irq()</code> also calls the scheduler before returning.<br />
<br />
This scheme of IRQ handling can be changed by rewriting the crt0 and changing the IVOR setup. In this way it is possible, for example, to use hardware vector mode. Please note that it is important that the end-of-interrupt be issued before calling the scheduler, as the scheduler may not return when a new task is to be scheduled.<br />
<br />
===Use of non volatile registers in Erika PowerPC===<br />
<br />
Some Erika RTOS assembly modules in PowerPC use non volatile registers for their internal purposes (r14-r31). Such modules are:<br />
<br />
* ee_e200zx_contex.S - This module is in charge of managing context switch for multistack on e200zx. In this module r14-r31 are saved and restored in a prologue and epilogue;<br />
* ee_oo.S - This module is in charge of saving and restoring registers for Osek TerminateTask() on e200zx. In this module r14-r31 are saved and restored in a prologue and epilogue;<br />
* ee_entry.S - This module handles exception entry points and hardware setup for the e200zx. In this module the istruction stmw uses r28-r30 to initialize SRAM. This code is stripped if a custom ISR table is used (see EE_ISR_EXTERNAL_TABLE for details);<br />
* ee_boot.S - This module represents boot sequence for PowerPC MCUs. The erika boot sequence accesses non volatile registers in init phase. This code can be removed from build process (see __USE_CUSTOM_CRT0__ for details).<br />
<br />
The use of r14-r31 registers is limited, just few lines of code. But this information is relevant in case advanced features of some compilers are used, (e.g.: to define additional non-standard SDAs, Small Data Area). For instance Windriver Diab compiler has the REGISTER directive in the linker script to fullfill this requirement. If this non-standard approach is not required this information can be neglected. It is provided in order to give the position of such code whenever the use of non volatile registers (r14-r31) is necessary for non-standard purposes. For details please refere to your compiler documentation.<br />
<br />
'''Assumption for future development:''' additional SDA base addresses will be stored starting from register r14<br />
<br />
== Download and install of Eclipse, RT-Druid, and ERIKA source ==<br />
<br />
To build an ERIKA application you need:<br />
* ERIKA source code<br />
* RT-Druid and a hosting Eclipse<br />
* Some command-line tools<br />
<br />
=== ERIKA source code ===<br />
<br />
ERIKA source code is bundled with RT-Druid. ERIKA for PPC e200 honors the definition of '''ERIKA_FILES''', so you can use the latest version of ERIKA as explained in [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]].<br />
<br />
=== Eclipse and RT-Druid in one piece ===<br />
<br />
A complete version of an Eclipse installation together with the RT-Druid plugin can be downloaded from this page:<br />
http://erika.tuxfamily.org/erika-for-multiple-devices.html. Please make sure to use a version not older than 1.6.0 beta. See also [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application]].<br />
<br />
=== Eclipse and RT-Druid piece by piece ===<br />
<br />
Alternatively, if you already have a copy of Eclipse or you want to use a version of Eclipse different from the one provided by the page above, you can follow this procedure.<br />
* To download the e200 plug-in for Eclipse refer the following site: [http://download.tuxfamily.org/erika/webdownload/rtdruid_beta Plug-in download site].<br />
Procedure for installation:<br />
* Step 0:<br />
: Get ''Eclipse'' and required plug-ins;<br />
: Where possible, the suggestion is to download the ''all in one update site'' and use the eclipse update manager or to use the eclipse update manager directly on a web site;<br />
:* Eclipse<br />
:: If you don't have any eclipse installations, you can download eclipse with cdt already installed from [http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/heliossr1 Eclipse IDE for C/C++].<br />
:: It is also possible use an already installed distribution of eclipse or to download one (for example from [http://www.eclipse.org/downloads Eclipse Downloads]) and then add all missing plug-ins.<br />
:* EMF<br />
:: The main page to download EMF is [http://www.eclipse.org/modeling/emf/downloads/?project=emf Eclipse Modeling Framework].<br />
:: The version to download is related to the eclipse version: eclipse 3.3 -> emf 2.3 , eclipse 3.4 -> emf 2.4, eclipse 3.5 -> emf 2.5, eclipse 3.6 -> emf 2.6. <br />
:: The list of required plugins is:<br />
::: org.eclipse.emf.common<br />
::: org.eclipse.emf.ecore<br />
::: org.eclipse.emf.edit<br />
::: org.eclipse.emf.common.ui<br />
::: org.eclipse.emf.edit.ui<br />
:: Clearly it is possible to install more plugins, like the whole emf runtime or sdk<br />
:* CDT<br />
:: The main page to download CDT is [http://www.eclipse.org/cdt/downloads.php CDT Downloads].<br />
:: Also here, the version to download is related to eclipse version. <br />
:: In this case is required only the cdt runtime plugin.<br />
: [http://erika.tuxfamily.org/forum/viewtopic.php?f=6&t=651&sid=89784e2d97765c3f1c41f6e3c049437a#p727 Forum Post (in italian) about installing the Eclipse plugins]<br />
* Step 1:<br />
: Open ''Eclipse'';<br />
: From the menu ''Help'' select ''Install New Software...'';<br />
: Add with the button ''Add...'' the reference site mentioned above (fill the Location field with this: http://download.tuxfamily.org/erika/webdownload/rtdruid_beta);<br />
: Tick all plug-ins related to RT-Druid core and to Erika Enterprise, then click on the button ''Next'' to install them;<br />
: Restart Eclipse;<br />
* Step 2:<br />
: From the menu ''File'' select ''New'' and then RT-Druid Oil and C/C++ Project;<br />
: From the Project menu select one of the available e200 demo tests;<br />
: Then click on the project name with the right mouse button and build to obtain the elf object module for debugging;<br />
<br />
=== Additional software ===<br />
<br />
ERIKA uses GNU make and some command-line utilities to build programs. You need the following tools (please notice that only the less common commands are listed here; very common commands that are present in any Unix/POSIX system like ''ls'' are not listed for simplicity):<br />
* make (GNU version)<br />
* gawk (GNU AWK)<br />
* sed<br />
* grep<br />
<br />
For Linux the above commands are present in virtually every standard installation; but you can always install them from the respective packages of your distributions.<br />
<br />
For Windows, [http://www.cygwin.com/ Cygwin] is recommended. Please make sure to include the above packages (package names are the same as the tool names).<br />
<br />
== HOWTOs ==<br />
* [[How to create, compile and debug an application for Freescale MPC5674F]]<br />
* [[How to run the MODISTARC regression tests for Freescale MPC5674F]]<br />
<br />
<br />
[[Category:Supported Devices]]</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Freescale_PPC_e200_(MPC_56xx)Freescale PPC e200 (MPC 56xx)2014-07-18T13:28:08Z<p>Francesco: /* Use of non volatile registers in Erika PowerPC */</p>
<hr />
<div>= Freescale PPC e200 (MPC 56xx) support =<br />
ERIKA Enterprise supports the PPC e200 family microcontrollers.<br />
The support for RT-Druid is available starting from release 1.5.0.<br />
The support includes: <br />
# Support MPC5674F (e200z7). MPC5668G (e200z6) is supported in version 1.6.0; version 1.6.1 will support both cores (z6 and z0) of the MPC5668G (already available on the [[ERIKA Enterprise and RT-Druid SVN Access|Subversion repository]]). Support for MPC5643L (e200z4).<br />
# Support for the WindRiver DIAB and Freescale CodeWarrior compilers.<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers<br />
** WindRiver DIAB C Compiler 5.5.1 and 5.8.0.<br />
** Freescale CodeWarrior:<br />
*** Windows: CodeWarrior Development Studio for MPC55xx/56xx 2.7<br />
*** Linux: CodeWarrior Development Studio for MCU 10.2<br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: Currently limited to the MPC5668G and MPC5643L, it follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ Autosar]: two instances of the operating systems run on the two cores, and communication between cores is performed with a few APIs and shared memory.<br />
<br />
* MMU Handling<br />
** Static global mappings to let all the application see all the memory/peripherals in the system; no memory protection is implemented and all the code is executed in supervisor mode.<br />
<br />
== Host Configuration ==<br />
<br />
* RT-Druid requires Java 1.6.<br />
* It is possible to use a version of ERIKA more recent than the one provided with RT-Druid; just download the ERIKA tree from the repository (see [[ERIKA Enterprise and RT-Druid SVN Access]]) and point the '''ERIKA_FILES''' environment variable to its location; see [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]] for some caveats.<br />
<br />
=== Wind River Diab ===<br />
* Compiler: The compiler commands (dcc, das, dld, and dar) are assumed to be reachable from the $PATH. If a specific version of them has to be used it must be specified in pkg/cfg/arch/cc_z7diab.mk<br />
* Operating system: The PPC e200 port has been developed under Debian testing/unstable as of May 2010; the only known requirement is Java 1.6 to run RT-Druid.<br />
* In the reference environment, the Diab toolchain was located in /opt/case/diabdata/<version> and Eclipse in /opt/eclipse. No hard requirement is made by the build system, as specified above. <br />
<br />
=== Freescale CodeWarrior ===<br />
*Compiler: The compiler directory can be specified using the environment variable '''PPC_CW_BASEDIR'''; this directory must contain the directories ''PA_Support'', and ''PA_Tools'' or ''PowerPC_EABI_Tools''. ERIKA makefiles find all the files they need with relatives paths from there. Please notice that makefiles require that the variable '''PPC_CW_BASEDIR''' do not contain any space. An evaluation or a limited version of the compiler can be downloaded from the [http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_DOWNLOADS Freescale Web site].<br />
*Operating system: both Linux and Windows are supported. CodeWarrior support has been developed under Debian Linux and Windows XP, but other (and more recent) versions should work. On Windows, ''Special Edition: CodeWarrior for Microcontrollers 10.5'' is currently used, and on Linux ''CodeWarrior Development Studio for MCU'' version 10.2. On Windows the Cygwin environment is used for ERIKA makefiles, so the '''PPC_CW_BASEDIR''' variable must use forward slashes '/' and must not contain spaces; you can always convert the path with the ''cygpath'' command. For example, in this case the value to use is <code>/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7</code>:<br />
$ cygpath.exe `cygpath.exe -ms "/c/Program Files/Freescale/CW for MPC55xx and MPC56xx 2.7"`<br />
/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7<br />
*OIL file: Currently, an ''EEOPT'' with value '''"__CODEWARRIOR__"''' must be specified in the OIL file. See [[#OIL file configuration]] for more details.<br />
<br />
== Target configuration and programming==<br />
<br />
* ERIKA is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]<br />
* ERIKA supports the Freescale MPC5674F, MPC5668G and MPC5643L MCUs (we have been able to run it on an MPC56XX and others; Freescale MCUs are really very similar).<br />
* At system boot the interrupt controller is set up to work in Software Vector Mode, and all the interrupts are associated to default handlers. The kernel does not use any specific device/interrupts, although for testing purposes it is possible to use the decrementer and some gpios as interrupt sources. All the code is executed from flash, all the data sections are loaded into the SRAM at boot time (the MMU is configured to provide 1:1 mappings for code running in system mode for all the sensible regions, like flash, sram and device registers).<br />
* The version in the repository supports both FLE and VLE modes.<br />
* The scripts generated by the build process are compatible with Lauterbach v200912. The commands generated to setup the NEXUS port are not compatible with older releases of the Lauterbach software. In case you hit this problem, remove the NEXUS.* lines from the generated scripts, ad set up the port according to the Lauterbach version you are using.<br />
* Target registers are used according the PPC ABI described in the DIAB manual.<br />
* The stack fill pattern is configurable at compile time, but is assumed to be 0xa5.<br />
* For Osek conformance classes, which support TerminateTask(), each running task requires 96 bytes of stack. <br />
For multistack configurations, 76 bytes are required on each stack for context switching. You can add this numbers to the requirements of your application to estimate task usage.<br />
* Stack pointer is aligned at 16 byte (fixed in version 1.6)<br />
<br />
=== MCUs ===<br />
* The MCUs supported are currently the following:<br />
** MPC5674F (Mamba)<br />
** MPC5668G (Fado)<br />
** MPC5643L (Leopard)<br />
<br />
===OIL file configuration===<br />
For more information about configuration through OIL file, see [[Tutorial: RT-Druid and OIL basics]]. Here only the e200zX-specific part of OIL is described.<br />
;CPU (CPU_DATA)<br />
: CPU must be set to E200ZX. The exact model is specified with the '''MODEL''' item (supported values are '''E200Z0''', '''E200Z6''' , '''E200Z7''' and '''E200Z4'''. Generation of VLE code can be selected by setting '''VLE''' to '''TRUE'''; please notice that all the application and the OS code must have the same setting, as ERIKA makefiles do not support mixed programs. Size in byte of the shared stack can be specified with the optional '''SYS_STACK_SIZE''' item.<br />
: Example of a CPU_DATA section:<br />
CPU_DATA = PPCE200ZX {<br />
ID = "MainCpu";<br />
MODEL = E200Z7;<br />
APP_SRC = "main.c";<br />
MULTI_STACK = FALSE;<br />
VLE = FALSE;<br />
SYS_STACK_SIZE = 512;<br />
};<br />
:On multicore systems, one CPU_DATA instance can exist for each core. They must have different '''ID'''s. See [[ERIKA multicore support]] for more details about multicore systems on Erika.<br />
;MCU<br />
: MCU support is present for MPC5674F ,MPC5668G and MPC5643L. The only item supported is '''MODEL''', which can be either '''MPC5674F''', '''MPC5668G''' or '''MPC5643L'''. Most of the differences produced by this setting affect memory map and Lauterbach scripts.<br />
: Example:<br />
MCU_DATA = PPCE200ZX {<br />
MODEL = MPC5674F;<br />
};<br />
;System Timer<br />
Erika on PowerPC has a system timer based on PowerPC Decrementer. This feature is available for all supported MCUs: MPC5674F (Mamba), MPC5668G(Fado) and MPC5643L (Leopard). System time also requires CPU_CLOCK field to be set on CPU_DATA, hence CPU_CLOCK value must be added in CPU_DATA configuration to have a system timer configured.<br />
This is an example to configure Decrementer as System Timer:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_DECREMENTER";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "DECREMENTER";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
<br />
Furthermore for MPC5643L (Leopard) is available a system timer based on Freescale STM (System Timer Module), that is a device available in several Freescale PowerPC MCUs. In this case the following configuration must be take into account:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_STM";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
...<br />
...<br />
<br />
<br />
;EEOPTs<br />
: See also [[EEOPT]] for common EEOPTs.<br />
: Special options for the PPC e200 ERIKA porting can be specified through '''EE_OPT''' items in the '''OS''' section (please notice that the value for an '''EE_OPT''' is a string, so double quotes (") must be added around the values in this list.<br />
:; EE_SYSTEM_TIMER_DEVICE_DECREMENTER (see system timer section above)<br />
:; EE_SYSTEM_TIMER_DEVICE_STM (available only for MPC5643L, see system timer section above)<br />
:;EE_ISR_DYNAMIC_TABLE<br />
::Used to enable dynamic ISR table support that let register ISR handlers at runtime calling <code>EE_e200z7_register_ISR</code>.<br />
:;__E200ZX_EXECUTE_FROM_RAM__<br />
:: When specified, a linker script is used that maps both code and data in the RAM space. Executables produced with this option can be used only together with a debugger that loads the program in memory. By default, code and constant data are mapped to Flash, data to RAM.<br />
:;__CODEWARRIOR__<br />
:: Invoke Freescale CodeWarrior compiler. See [[#Freescale CodeWarrior]] for information on how to configure the compiler. The default compiler is Wind River Diab; see [[#Wind River Diab]] for configuration.<br />
:;__USE_CUSTOM_LINKER_SCRIPT__<br />
:: Don't use the dafault linker script. Users can direct the linker to use their own linker script by setting the <code>LDFLAGS</code> variable. Example:<br />
OS EE {<br />
EE_OPT = "__USE_CUSTOM_LINKER_SCRIPT__";<br />
LDFLAGS = "../my_linker_script.ld";<br />
};<br />
:;__USE_CUSTOM_CRT0__<br />
:: Don't use Erika default crt0. Users can provide their own crt0 by adding source files in the usual way (APP_SRC in the OIL file).<br />
;;__MINIMAL_CC_OPTIONS__<br />
:: Enable only the compiler flags absolutely needed to compile Erika, so users can easily add their preferences in CFLAGS.<br />
;;__EE_USE_MMU__<br />
:: Enable the MMU support. The MMU can be configured by calling <code>EE_e200zx_mmu_setup()</code>. See the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> for more details. An example configuration can be found in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt>.<br />
;;__EE_CRT0_INIT_MMU__<br />
:: Initialize the MMU from the crt0. See <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt> for an example, and the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt>.<br />
;;EE_NO_LIBEE<br />
:: To not generete the kernel library '''libee.a''' but link all the objects files (kernel + application) directly in an elf file. This option is useful to try Erika with CodeWarrior compiler with an evaluation license, because the archiver is not enabled with this license.<br />
;;DEBUG<br />
:: On this architecture, enabling debug symbols does not inhibit optimization.<br />
;;MPC5643L_STD_SW_MMU_CONFIG"<br />
:: This EE_OPT is valid only for MPC5643L (Leopard) and provides a standard (and in most cases sufficient) MMU configuration. This option is useful expecially running your code from FLASH where Debugger does not initializes the MMU for you.<br />
;;EE_LAUTERBACH_DEMO_SIM<br />
:: This option is available only for Mamba (MPC5674F), for details please take a look at DEMO_ErikaSim in the directory of templates. It causes the generation of Lauterbach scripts to use with Lauterbach simulator.<br />
<br />
There are a few examples in the ERIKA code base that can be used as a starting point for new projects. Examples include also a makefile, which can be used to compile a project without a need of an IDE. The makefile runs RT-Druid non-interactively, and requires the environment variable '''RTDRUID_ECLIPSE_HOME''' to point to the Eclipse directory where RT-Druid is installed.<br />
<br />
Examples can be accessed as templates in RT-Druid (see [[How to create, compile and debug an application for Freescale MPC5674F]]), or directly in the source code: [http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/ examples/ppc/].<br />
<br />
In the first version of ERIKA and RT-Druid supporting e200zX, the only e200-specific setting in the OIL configuration file was the CPU_DATA value, which had to be set to '''MPC5674F''' instead of '''PPCE200ZX'''. This not supported any more.<br />
<br />
=== APIs ===<br />
* List of functions (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_irq.h?view=markup pkg/cpu/e200zx/inc/ee_irq.h]</tt> for prototypes and other details):<br />
** EE_e200z7_register_ISR(level, handler, priority): Associate <tt>handler</tt> to the IRQ <tt>level</tt>, with the given <tt>priority</tt> (available only if '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' is set).<br />
** EE_e200z7_setup_decrementer(delay): Configure the decrementer to raise an interrupt every <tt>delay</tt> cycles.<br />
** EE_e200z7_setup_decrementer_oneshot(delay): Configure the decrementer to raise an interrupt <tt>delay</tt> cycles after invocation.<br />
** EE_e200z7_stop_decrementer(): Stop the decrementer from generating interrupts.<br />
** EE_e200zx_setup_fixed_intv(bitpos): Enable the fixed-interval interrupt.<br />
** EE_e200zx_stop_fixed_intv(): Disable the fixed-interval interrupt.<br />
** EE_e200zx_mmu_setup(entries, count): MMU initialization.<br />
<br />
Note: notice that the *_e200z7_* is slightly misleading since it seem to refer only to e200z7 family, it is a legacy name convention when the only supported architecture by Erika was Z7. Currently even Z0, Z4 and Z6 are supported hence these functions can be used for such architectures, although it refers to *_e200z7_*.<br />
<br />
====Interrupts====<br />
<br />
There are two way to configure ISR. The standard way is the static way with OIL configuration (example):<br />
<br />
ISR DecrIsr {<br />
CATEGORY = 2;<br />
ENTRY = "DECREMENTER";<br />
};<br />
<br />
ISR FixedIntvIsr {<br />
CATEGORY = 2;<br />
ENTRY = "FIXED_INTV";<br />
HANDLER = "fixed_intv_handler";<br />
};<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
ENTRY = "0";<br />
};<br />
ISR IsrMedium {<br />
CATEGORY = 2;<br />
PRIORITY = 2;<br />
ENTRY = "1";<br />
};<br />
<br />
ISR IsrHigh {<br />
CATEGORY = ;<br />
PRIORITY = 3;<br />
ENTRY = "2";<br />
HANDLER = "isr_high_handler";<br />
};<br />
<br />
In static ISR table handling mode there's full support for both ISR1 and ISR2 for '''external interrupt'''. To register an handler you should use the suitable macro ('''ISR1''' or '''ISR2''') passing the value of '''HANDLER''' field or the '''ISR name''', in case the former is missing. The configuration field '''ENTRY''' declare the position of the handler inside the vector table (the example show three handlers that get the first three positions in vector, corrisponding to the first three software interrupt request). Priority field corripsond to interrupt priority value set to corrisponding Interrupt Controller Priority select registers ('''INTC.PSR[(ENTRY)] = PRIORITY'''), the values have to be inside [0..15] range.<br />
<br />
There is direct support for two cpu '''internal exceptions''', those generated by the time base facilities: decrementer and fixed interval timer ('''ENTRY = "DECREMENTER"''' and '''ENTRY = "FIXED_INTV"'''' respectively.). Support for Watch-Dog timer will be added. To register an handler for internal interrupt you have to use '''ISR1_INT''' or '''ISR2_INT''' (two different couple of macros are needed to issue EOI, End Of Interrupt, only for external interrupts). Priority field in configuration have no meaning for internal interrupts.<br />
<br />
You can register handler by code dinamically with with the <code>EE_e200z7_register_ISR()</code> described above. To enable dynamic ISR table support you must declare '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' configuration OIL file. The '''first 16 level''' of dynamic table are reserved for '''internal exceptions''' handlers, so you have to add this offset to the '''ENTRY''' value of the static approach to register an handler to the same interrupt source.<br />
<br />
ISRs (Interrupt Service Routines) are just void functions with no arguments. For external interrupts (IVOR4), the EOI (End Of Interrupt) is issued by ERIKA's handler; user ISRs need not bother about that.<br />
<br />
====Multicore support (MPC5668 and MPC5643L)====<br />
* Functions used for multicore support on MPC5668 (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5668/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5668/inc/ee_dual.h]</tt> for prototypes and other details):<br />
** EE_mpc5668_start_z0(f): Enable the z0 CPU.<br />
<br />
The same paradigm of multicore support available for MPC5668G, is also available for the MPC5643L, (for details see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5643l/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5643l/inc/ee_dual.h]</tt>). Likewise MPC5668G, in order to start the slave core, a EE_mpc5643l_start_slave(f) call has to be provided at startup (typically in main function) immediately before the StartOS().<br />
<br />
=== Boards ===<br />
* ERIKA has been developed on an '''Axiom MPC5674evbfxmb evaluation board'''. This evaluation board has the MAMBA microcontroller (Freescale MPC5674F)<br />
** The kernel has no dependency on the board itself, but some of its functionalities can be used for debugging purposes. Including file "pkg/board/axiom_mpc5674fxmb/inc/ee_board.h" the following functions can be used:<br />
*** EE_leds_init(): which sets up the GPIOs associated with the leds.<br />
*** EE_EE_leds(mask): which turns the i-th led on or off depending on the state of the i-th bit in the mask passed as an argument.<br />
*** EE_led_<X>_on()/EE_led_<X>_off(): turns led X on or off.<br />
*** EE_buttons_disable_interrupts(button): disables the interrupt associated to the given button.<br />
*** EE_buttons_enable_interrupts(button): enables it.<br />
*** EE_buttons_clear_ISRflag(button): acknowledges the interrupt coming from the given button.<br />
*** EE_button_get_B<X>(): gets the status of button X.<br />
*** EE_buttons_init(): initializes the GPIOs associated to buttons.<br />
** The functions above are available if, respectively, __USE_LEDS__ and __USE_BUTTONS__ are defined upon inclusion of ee_board.h<br />
** The connections are assumed to be the following:<br />
*** GPIO 147-150: connected to LED0-3. Looking at the pins on the EVB:<br />
**** ETPUB1 -> USER_LED1<br />
**** ETPUB2 -> USER_LED2<br />
**** ETPUB3 -> USER_LED3<br />
*** GPIO 450: connected to BUTTON0 (ETPUC9 -> USER_DEV1)<br />
<br />
* Erika is available for the '''Freescale MPC5668EVB Evaluation Board'''. This evaluation board has the FADO microcontroller (Freescale MPC5668G)<br />
** for this board the are no available support for leds or buttons.<br />
<br />
* Erika is available for '''Freescale MPC564xLEVB Evaluation Board'''. This evaluation board has the LEOPARD microcontroller (Freescale MPC5643L)<br />
** for this board there is the same set of primitives defined for "Axiom MPC5674evbfxmb" board, hence a basic support for leds and button is available.<br />
<br />
== Multicore support ==<br />
<br />
In the ERIKA multicore support for PPC e200 there are a few aspects specific to the PPC e200 architecture, and they are described here. Please refer to [[ERIKA multicore support]] for general information on ERIKA multicore systems.<br />
<br />
The PPC evaluation board supported by Erika Multicore is the Freescale MPC5668G/E Evaluation kit, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5668GKIT. The multicore support is also provided for MPC5643L with the Freescale evaluation board MPC564xL EVB, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=XKT564L.<br />
<br />
In multicore configuration, is it possible running both instances of the operating system both in RAM and Flash. For instance on MPC5668G, the internal SRAM is partitioned statically in two: memory from 0x40000000 to 0x4001FFFF is reserved to the first core and shared variables, while memory from 0x40020000 to 0x4003FFFF is reserved to the second core. 0x40020000 is used as the starting address of the second core. A similar approach is available for MPC5643L. In order to customize such memory assignments please refer to memory0.ld and memory1.ld files in "erika/pkg/mcu/freescale_mpc56XX/cfg/multicore" (where XX=43l for Leopard and XX=68 for Fado).<br />
<br />
Shared variable data is allocated in a single section (<tt>.mcglobald</tt>). Access to this section must be performed without cache, or the OS may malfunction. ERIKA crt0 does not enable cache; if you want to enable it, you should also make sure that the <tt>.mcglobald</tt> section is allocated on a page on its own by the linker script, and that the MMU is configured to mark such page as non-cached. <br />
<br />
The OS uses two software interrupts (6 and 7) and two hardware semaphores (0 and 1) of the MPC5668G to handle inter-core communication. They are initialised inside <code>StartOS()</code>. While all the other software interrupts and semaphores are available for user applications, those used by the OS should not be meddled with by user code. It is okay to briefly mask the interrupts with higher-priority interrupts or by disabling interrupts. In case of MPC5643L, as the microcontroller has two different interrupt controllers (one for each core), SW interrupt number 7 is used for both cores. Even if the MPC5643L has two SEMA4 modules, only the first module (the one associated to the master core) is used for this mechanism, this means that semaphores 0 and 1 of the first SEMA4 module are used for synchronisation (as in MPC5668G), while the remaining semaphores of the first SEMA4 module and all semaphores belonging to the second SEMA4 module are available for user applications.<br />
<br />
Examples of multicore applications are in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/ examples/ppc/dual_examples]</tt>. In particular, <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/mono_activate01/ examples/ppc/dual_examples/mono_activate01]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/multi_event01/ examples/ppc/dual_examples/multi_event01]</tt> are complete applications, nearer to real-world usage.<br />
<br />
Erika multicore for PowerPC supports AUTOSAR OS-like functionalities. For details please see the following page (but take into account that these features have not been published yet):<br />
[[Erika AUTOSAR OS]]<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for PPC e200 produces a Lauterbach Trace32 configuration file (<tt>t32.cmm</tt>) and a ORTI description file (<tt>system.orti</tt>) inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger, please issue <code>t32mppc</code> from the output directory. The ERIKA build system honors the <tt>T32SYS</tt> environment variable, if set.<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named <tt>start.sh</tt>) is produced in the output directory. To run the debugger, please issue <code>start.sh</code> from the output directory. The script creates two instances of the debugger, one for each core. For instace when MPC5668G is turned on, only the first (Z6) core is enabled. In order to simulate the real setup, the debugger connected to the second (Z0) core does not enable its core, but it is responsibility of the code running on the Z6 core to enable the Z0 core (this is different from the example script for MPC5668G distributed with the Lauterbach Trace32 software). Nonetheless, the startup script loads all the code and the debug symbols for both core and both debugger instances. In a typical debugging session, you start the execution of the code on the Z6 core from its debugger, and then, when the Z0 core has become active, start also the code on the Z0 core from the Z0 debugger. The barrier inside <code>StartOS()</code> comes handy to synchronize the code running on the two cores. The <tt>start.sh</tt> script runs only on Linux; currently the ERIKA build system does not support Windows to run Trace32 for e200 multicore systems. A similar approach has been adopted for MPC5643L.<br />
<br />
==Internals==<br />
<br />
===Interrupts===<br />
<br />
Interrupt handling in PPC e200 ERIKA uses software vector mode and a single entry point for all interrupts and exceptions, which is <code>EE_e200z7_irq()</code>. This function calls the user ISR and issues the end-of-interrupt for external interrupts; when the served interrupt is not nested, i.e., it interrupted a task directly, <code>EE_e200z7_irq()</code> also calls the scheduler before returning.<br />
<br />
This scheme of IRQ handling can be changed by rewriting the crt0 and changing the IVOR setup. In this way it is possible, for example, to use hardware vector mode. Please note that it is important that the end-of-interrupt be issued before calling the scheduler, as the scheduler may not return when a new task is to be scheduled.<br />
<br />
===Use of non volatile registers in Erika PowerPC===<br />
<br />
Some Erika RTOS assembly modules in PowerPC use non volatile registers for their internal purposes (r14-r31). Such modules are:<br />
<br />
* ee_e200zx_contex.S - This module is in charge of managing context switch for multistack on e200zx. In this module r14-r31 are saved and restored in a prologue and epilogue;<br />
* ee_oo.S - This module is in charge of saving and restoring registers for Osek TerminateTask() on e200zx. In this module r14-r31 are saved and restored in a prologue and epilogue;<br />
* ee_entry.S - This module handles exception entry points and hardware setup for the e200zx. In this module the istruction stmw uses r28-r30 to initialize SRAM. This code is stripped if a custom ISR table is used (see EE_ISR_EXTERNAL_TABLE for details);<br />
* ee_boot.S - This module represents boot sequence for PowerPC MCUs. The erika boot sequence accesses non volatile registers in init phase. This code can be removed from build process (see __USE_CUSTOM_CRT0__ for details).<br />
<br />
The use of r14-r31 registers is limited, just few lines of code. But this information is relevant in case advanced features of some compilers are used, (e.g.: to define additional non-standard SDAs, Small Data Area). For instance Windriver Diab compiler has the REGISTER directive in the linker script to fullfill this requirement. If this non-standard approach is not required this information can be neglected. It is provided in order to give the position of such code whenever the use of non volatile registers (r14-r31) is necessary for non-standard purposes. For details please refere to your compiler documentation.<br />
<br />
'''Assumption for future development:''' additional SDA base addresses will be stored starting from register r14<br />
<br />
== Download and install of Eclipse, RT-Druid, and ERIKA source ==<br />
<br />
To build an ERIKA application you need:<br />
* ERIKA source code<br />
* RT-Druid and a hosting Eclipse<br />
* Some command-line tools<br />
<br />
=== ERIKA source code ===<br />
<br />
ERIKA source code is bundled with RT-Druid. ERIKA for PPC e200 honors the definition of '''ERIKA_FILES''', so you can use the latest version of ERIKA as explained in [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]].<br />
<br />
=== Eclipse and RT-Druid in one piece ===<br />
<br />
A complete version of an Eclipse installation together with the RT-Druid plugin can be downloaded from this page:<br />
http://erika.tuxfamily.org/erika-for-multiple-devices.html. Please make sure to use a version not older than 1.6.0 beta. See also [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application]].<br />
<br />
=== Eclipse and RT-Druid piece by piece ===<br />
<br />
Alternatively, if you already have a copy of Eclipse or you want to use a version of Eclipse different from the one provided by the page above, you can follow this procedure.<br />
* To download the e200 plug-in for Eclipse refer the following site: [http://download.tuxfamily.org/erika/webdownload/rtdruid_beta Plug-in download site].<br />
Procedure for installation:<br />
* Step 0:<br />
: Get ''Eclipse'' and required plug-ins;<br />
: Where possible, the suggestion is to download the ''all in one update site'' and use the eclipse update manager or to use the eclipse update manager directly on a web site;<br />
:* Eclipse<br />
:: If you don't have any eclipse installations, you can download eclipse with cdt already installed from [http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/heliossr1 Eclipse IDE for C/C++].<br />
:: It is also possible use an already installed distribution of eclipse or to download one (for example from [http://www.eclipse.org/downloads Eclipse Downloads]) and then add all missing plug-ins.<br />
:* EMF<br />
:: The main page to download EMF is [http://www.eclipse.org/modeling/emf/downloads/?project=emf Eclipse Modeling Framework].<br />
:: The version to download is related to the eclipse version: eclipse 3.3 -> emf 2.3 , eclipse 3.4 -> emf 2.4, eclipse 3.5 -> emf 2.5, eclipse 3.6 -> emf 2.6. <br />
:: The list of required plugins is:<br />
::: org.eclipse.emf.common<br />
::: org.eclipse.emf.ecore<br />
::: org.eclipse.emf.edit<br />
::: org.eclipse.emf.common.ui<br />
::: org.eclipse.emf.edit.ui<br />
:: Clearly it is possible to install more plugins, like the whole emf runtime or sdk<br />
:* CDT<br />
:: The main page to download CDT is [http://www.eclipse.org/cdt/downloads.php CDT Downloads].<br />
:: Also here, the version to download is related to eclipse version. <br />
:: In this case is required only the cdt runtime plugin.<br />
: [http://erika.tuxfamily.org/forum/viewtopic.php?f=6&t=651&sid=89784e2d97765c3f1c41f6e3c049437a#p727 Forum Post (in italian) about installing the Eclipse plugins]<br />
* Step 1:<br />
: Open ''Eclipse'';<br />
: From the menu ''Help'' select ''Install New Software...'';<br />
: Add with the button ''Add...'' the reference site mentioned above (fill the Location field with this: http://download.tuxfamily.org/erika/webdownload/rtdruid_beta);<br />
: Tick all plug-ins related to RT-Druid core and to Erika Enterprise, then click on the button ''Next'' to install them;<br />
: Restart Eclipse;<br />
* Step 2:<br />
: From the menu ''File'' select ''New'' and then RT-Druid Oil and C/C++ Project;<br />
: From the Project menu select one of the available e200 demo tests;<br />
: Then click on the project name with the right mouse button and build to obtain the elf object module for debugging;<br />
<br />
=== Additional software ===<br />
<br />
ERIKA uses GNU make and some command-line utilities to build programs. You need the following tools (please notice that only the less common commands are listed here; very common commands that are present in any Unix/POSIX system like ''ls'' are not listed for simplicity):<br />
* make (GNU version)<br />
* gawk (GNU AWK)<br />
* sed<br />
* grep<br />
<br />
For Linux the above commands are present in virtually every standard installation; but you can always install them from the respective packages of your distributions.<br />
<br />
For Windows, [http://www.cygwin.com/ Cygwin] is recommended. Please make sure to include the above packages (package names are the same as the tool names).<br />
<br />
== HOWTOs ==<br />
* [[How to create, compile and debug an application for Freescale MPC5674F]]<br />
* [[How to run the MODISTARC regression tests for Freescale MPC5674F]]<br />
<br />
<br />
[[Category:Supported Devices]]</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Freescale_PPC_e200_(MPC_56xx)Freescale PPC e200 (MPC 56xx)2014-07-18T13:26:00Z<p>Francesco: /* Use of non volatile registers in Erika PowerPC */</p>
<hr />
<div>= Freescale PPC e200 (MPC 56xx) support =<br />
ERIKA Enterprise supports the PPC e200 family microcontrollers.<br />
The support for RT-Druid is available starting from release 1.5.0.<br />
The support includes: <br />
# Support MPC5674F (e200z7). MPC5668G (e200z6) is supported in version 1.6.0; version 1.6.1 will support both cores (z6 and z0) of the MPC5668G (already available on the [[ERIKA Enterprise and RT-Druid SVN Access|Subversion repository]]). Support for MPC5643L (e200z4).<br />
# Support for the WindRiver DIAB and Freescale CodeWarrior compilers.<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers<br />
** WindRiver DIAB C Compiler 5.5.1 and 5.8.0.<br />
** Freescale CodeWarrior:<br />
*** Windows: CodeWarrior Development Studio for MPC55xx/56xx 2.7<br />
*** Linux: CodeWarrior Development Studio for MCU 10.2<br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: Currently limited to the MPC5668G and MPC5643L, it follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ Autosar]: two instances of the operating systems run on the two cores, and communication between cores is performed with a few APIs and shared memory.<br />
<br />
* MMU Handling<br />
** Static global mappings to let all the application see all the memory/peripherals in the system; no memory protection is implemented and all the code is executed in supervisor mode.<br />
<br />
== Host Configuration ==<br />
<br />
* RT-Druid requires Java 1.6.<br />
* It is possible to use a version of ERIKA more recent than the one provided with RT-Druid; just download the ERIKA tree from the repository (see [[ERIKA Enterprise and RT-Druid SVN Access]]) and point the '''ERIKA_FILES''' environment variable to its location; see [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]] for some caveats.<br />
<br />
=== Wind River Diab ===<br />
* Compiler: The compiler commands (dcc, das, dld, and dar) are assumed to be reachable from the $PATH. If a specific version of them has to be used it must be specified in pkg/cfg/arch/cc_z7diab.mk<br />
* Operating system: The PPC e200 port has been developed under Debian testing/unstable as of May 2010; the only known requirement is Java 1.6 to run RT-Druid.<br />
* In the reference environment, the Diab toolchain was located in /opt/case/diabdata/<version> and Eclipse in /opt/eclipse. No hard requirement is made by the build system, as specified above. <br />
<br />
=== Freescale CodeWarrior ===<br />
*Compiler: The compiler directory can be specified using the environment variable '''PPC_CW_BASEDIR'''; this directory must contain the directories ''PA_Support'', and ''PA_Tools'' or ''PowerPC_EABI_Tools''. ERIKA makefiles find all the files they need with relatives paths from there. Please notice that makefiles require that the variable '''PPC_CW_BASEDIR''' do not contain any space. An evaluation or a limited version of the compiler can be downloaded from the [http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_DOWNLOADS Freescale Web site].<br />
*Operating system: both Linux and Windows are supported. CodeWarrior support has been developed under Debian Linux and Windows XP, but other (and more recent) versions should work. On Windows, ''Special Edition: CodeWarrior for Microcontrollers 10.5'' is currently used, and on Linux ''CodeWarrior Development Studio for MCU'' version 10.2. On Windows the Cygwin environment is used for ERIKA makefiles, so the '''PPC_CW_BASEDIR''' variable must use forward slashes '/' and must not contain spaces; you can always convert the path with the ''cygpath'' command. For example, in this case the value to use is <code>/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7</code>:<br />
$ cygpath.exe `cygpath.exe -ms "/c/Program Files/Freescale/CW for MPC55xx and MPC56xx 2.7"`<br />
/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7<br />
*OIL file: Currently, an ''EEOPT'' with value '''"__CODEWARRIOR__"''' must be specified in the OIL file. See [[#OIL file configuration]] for more details.<br />
<br />
== Target configuration and programming==<br />
<br />
* ERIKA is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]<br />
* ERIKA supports the Freescale MPC5674F, MPC5668G and MPC5643L MCUs (we have been able to run it on an MPC56XX and others; Freescale MCUs are really very similar).<br />
* At system boot the interrupt controller is set up to work in Software Vector Mode, and all the interrupts are associated to default handlers. The kernel does not use any specific device/interrupts, although for testing purposes it is possible to use the decrementer and some gpios as interrupt sources. All the code is executed from flash, all the data sections are loaded into the SRAM at boot time (the MMU is configured to provide 1:1 mappings for code running in system mode for all the sensible regions, like flash, sram and device registers).<br />
* The version in the repository supports both FLE and VLE modes.<br />
* The scripts generated by the build process are compatible with Lauterbach v200912. The commands generated to setup the NEXUS port are not compatible with older releases of the Lauterbach software. In case you hit this problem, remove the NEXUS.* lines from the generated scripts, ad set up the port according to the Lauterbach version you are using.<br />
* Target registers are used according the PPC ABI described in the DIAB manual.<br />
* The stack fill pattern is configurable at compile time, but is assumed to be 0xa5.<br />
* For Osek conformance classes, which support TerminateTask(), each running task requires 96 bytes of stack. <br />
For multistack configurations, 76 bytes are required on each stack for context switching. You can add this numbers to the requirements of your application to estimate task usage.<br />
* Stack pointer is aligned at 16 byte (fixed in version 1.6)<br />
<br />
=== MCUs ===<br />
* The MCUs supported are currently the following:<br />
** MPC5674F (Mamba)<br />
** MPC5668G (Fado)<br />
** MPC5643L (Leopard)<br />
<br />
===OIL file configuration===<br />
For more information about configuration through OIL file, see [[Tutorial: RT-Druid and OIL basics]]. Here only the e200zX-specific part of OIL is described.<br />
;CPU (CPU_DATA)<br />
: CPU must be set to E200ZX. The exact model is specified with the '''MODEL''' item (supported values are '''E200Z0''', '''E200Z6''' , '''E200Z7''' and '''E200Z4'''. Generation of VLE code can be selected by setting '''VLE''' to '''TRUE'''; please notice that all the application and the OS code must have the same setting, as ERIKA makefiles do not support mixed programs. Size in byte of the shared stack can be specified with the optional '''SYS_STACK_SIZE''' item.<br />
: Example of a CPU_DATA section:<br />
CPU_DATA = PPCE200ZX {<br />
ID = "MainCpu";<br />
MODEL = E200Z7;<br />
APP_SRC = "main.c";<br />
MULTI_STACK = FALSE;<br />
VLE = FALSE;<br />
SYS_STACK_SIZE = 512;<br />
};<br />
:On multicore systems, one CPU_DATA instance can exist for each core. They must have different '''ID'''s. See [[ERIKA multicore support]] for more details about multicore systems on Erika.<br />
;MCU<br />
: MCU support is present for MPC5674F ,MPC5668G and MPC5643L. The only item supported is '''MODEL''', which can be either '''MPC5674F''', '''MPC5668G''' or '''MPC5643L'''. Most of the differences produced by this setting affect memory map and Lauterbach scripts.<br />
: Example:<br />
MCU_DATA = PPCE200ZX {<br />
MODEL = MPC5674F;<br />
};<br />
;System Timer<br />
Erika on PowerPC has a system timer based on PowerPC Decrementer. This feature is available for all supported MCUs: MPC5674F (Mamba), MPC5668G(Fado) and MPC5643L (Leopard). System time also requires CPU_CLOCK field to be set on CPU_DATA, hence CPU_CLOCK value must be added in CPU_DATA configuration to have a system timer configured.<br />
This is an example to configure Decrementer as System Timer:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_DECREMENTER";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "DECREMENTER";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
<br />
Furthermore for MPC5643L (Leopard) is available a system timer based on Freescale STM (System Timer Module), that is a device available in several Freescale PowerPC MCUs. In this case the following configuration must be take into account:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_STM";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
...<br />
...<br />
<br />
<br />
;EEOPTs<br />
: See also [[EEOPT]] for common EEOPTs.<br />
: Special options for the PPC e200 ERIKA porting can be specified through '''EE_OPT''' items in the '''OS''' section (please notice that the value for an '''EE_OPT''' is a string, so double quotes (") must be added around the values in this list.<br />
:; EE_SYSTEM_TIMER_DEVICE_DECREMENTER (see system timer section above)<br />
:; EE_SYSTEM_TIMER_DEVICE_STM (available only for MPC5643L, see system timer section above)<br />
:;EE_ISR_DYNAMIC_TABLE<br />
::Used to enable dynamic ISR table support that let register ISR handlers at runtime calling <code>EE_e200z7_register_ISR</code>.<br />
:;__E200ZX_EXECUTE_FROM_RAM__<br />
:: When specified, a linker script is used that maps both code and data in the RAM space. Executables produced with this option can be used only together with a debugger that loads the program in memory. By default, code and constant data are mapped to Flash, data to RAM.<br />
:;__CODEWARRIOR__<br />
:: Invoke Freescale CodeWarrior compiler. See [[#Freescale CodeWarrior]] for information on how to configure the compiler. The default compiler is Wind River Diab; see [[#Wind River Diab]] for configuration.<br />
:;__USE_CUSTOM_LINKER_SCRIPT__<br />
:: Don't use the dafault linker script. Users can direct the linker to use their own linker script by setting the <code>LDFLAGS</code> variable. Example:<br />
OS EE {<br />
EE_OPT = "__USE_CUSTOM_LINKER_SCRIPT__";<br />
LDFLAGS = "../my_linker_script.ld";<br />
};<br />
:;__USE_CUSTOM_CRT0__<br />
:: Don't use Erika default crt0. Users can provide their own crt0 by adding source files in the usual way (APP_SRC in the OIL file).<br />
;;__MINIMAL_CC_OPTIONS__<br />
:: Enable only the compiler flags absolutely needed to compile Erika, so users can easily add their preferences in CFLAGS.<br />
;;__EE_USE_MMU__<br />
:: Enable the MMU support. The MMU can be configured by calling <code>EE_e200zx_mmu_setup()</code>. See the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> for more details. An example configuration can be found in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt>.<br />
;;__EE_CRT0_INIT_MMU__<br />
:: Initialize the MMU from the crt0. See <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt> for an example, and the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt>.<br />
;;EE_NO_LIBEE<br />
:: To not generete the kernel library '''libee.a''' but link all the objects files (kernel + application) directly in an elf file. This option is useful to try Erika with CodeWarrior compiler with an evaluation license, because the archiver is not enabled with this license.<br />
;;DEBUG<br />
:: On this architecture, enabling debug symbols does not inhibit optimization.<br />
;;MPC5643L_STD_SW_MMU_CONFIG"<br />
:: This EE_OPT is valid only for MPC5643L (Leopard) and provides a standard (and in most cases sufficient) MMU configuration. This option is useful expecially running your code from FLASH where Debugger does not initializes the MMU for you.<br />
;;EE_LAUTERBACH_DEMO_SIM<br />
:: This option is available only for Mamba (MPC5674F), for details please take a look at DEMO_ErikaSim in the directory of templates. It causes the generation of Lauterbach scripts to use with Lauterbach simulator.<br />
<br />
There are a few examples in the ERIKA code base that can be used as a starting point for new projects. Examples include also a makefile, which can be used to compile a project without a need of an IDE. The makefile runs RT-Druid non-interactively, and requires the environment variable '''RTDRUID_ECLIPSE_HOME''' to point to the Eclipse directory where RT-Druid is installed.<br />
<br />
Examples can be accessed as templates in RT-Druid (see [[How to create, compile and debug an application for Freescale MPC5674F]]), or directly in the source code: [http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/ examples/ppc/].<br />
<br />
In the first version of ERIKA and RT-Druid supporting e200zX, the only e200-specific setting in the OIL configuration file was the CPU_DATA value, which had to be set to '''MPC5674F''' instead of '''PPCE200ZX'''. This not supported any more.<br />
<br />
=== APIs ===<br />
* List of functions (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_irq.h?view=markup pkg/cpu/e200zx/inc/ee_irq.h]</tt> for prototypes and other details):<br />
** EE_e200z7_register_ISR(level, handler, priority): Associate <tt>handler</tt> to the IRQ <tt>level</tt>, with the given <tt>priority</tt> (available only if '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' is set).<br />
** EE_e200z7_setup_decrementer(delay): Configure the decrementer to raise an interrupt every <tt>delay</tt> cycles.<br />
** EE_e200z7_setup_decrementer_oneshot(delay): Configure the decrementer to raise an interrupt <tt>delay</tt> cycles after invocation.<br />
** EE_e200z7_stop_decrementer(): Stop the decrementer from generating interrupts.<br />
** EE_e200zx_setup_fixed_intv(bitpos): Enable the fixed-interval interrupt.<br />
** EE_e200zx_stop_fixed_intv(): Disable the fixed-interval interrupt.<br />
** EE_e200zx_mmu_setup(entries, count): MMU initialization.<br />
<br />
Note: notice that the *_e200z7_* is slightly misleading since it seem to refer only to e200z7 family, it is a legacy name convention when the only supported architecture by Erika was Z7. Currently even Z0, Z4 and Z6 are supported hence these functions can be used for such architectures, although it refers to *_e200z7_*.<br />
<br />
====Interrupts====<br />
<br />
There are two way to configure ISR. The standard way is the static way with OIL configuration (example):<br />
<br />
ISR DecrIsr {<br />
CATEGORY = 2;<br />
ENTRY = "DECREMENTER";<br />
};<br />
<br />
ISR FixedIntvIsr {<br />
CATEGORY = 2;<br />
ENTRY = "FIXED_INTV";<br />
HANDLER = "fixed_intv_handler";<br />
};<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
ENTRY = "0";<br />
};<br />
ISR IsrMedium {<br />
CATEGORY = 2;<br />
PRIORITY = 2;<br />
ENTRY = "1";<br />
};<br />
<br />
ISR IsrHigh {<br />
CATEGORY = ;<br />
PRIORITY = 3;<br />
ENTRY = "2";<br />
HANDLER = "isr_high_handler";<br />
};<br />
<br />
In static ISR table handling mode there's full support for both ISR1 and ISR2 for '''external interrupt'''. To register an handler you should use the suitable macro ('''ISR1''' or '''ISR2''') passing the value of '''HANDLER''' field or the '''ISR name''', in case the former is missing. The configuration field '''ENTRY''' declare the position of the handler inside the vector table (the example show three handlers that get the first three positions in vector, corrisponding to the first three software interrupt request). Priority field corripsond to interrupt priority value set to corrisponding Interrupt Controller Priority select registers ('''INTC.PSR[(ENTRY)] = PRIORITY'''), the values have to be inside [0..15] range.<br />
<br />
There is direct support for two cpu '''internal exceptions''', those generated by the time base facilities: decrementer and fixed interval timer ('''ENTRY = "DECREMENTER"''' and '''ENTRY = "FIXED_INTV"'''' respectively.). Support for Watch-Dog timer will be added. To register an handler for internal interrupt you have to use '''ISR1_INT''' or '''ISR2_INT''' (two different couple of macros are needed to issue EOI, End Of Interrupt, only for external interrupts). Priority field in configuration have no meaning for internal interrupts.<br />
<br />
You can register handler by code dinamically with with the <code>EE_e200z7_register_ISR()</code> described above. To enable dynamic ISR table support you must declare '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' configuration OIL file. The '''first 16 level''' of dynamic table are reserved for '''internal exceptions''' handlers, so you have to add this offset to the '''ENTRY''' value of the static approach to register an handler to the same interrupt source.<br />
<br />
ISRs (Interrupt Service Routines) are just void functions with no arguments. For external interrupts (IVOR4), the EOI (End Of Interrupt) is issued by ERIKA's handler; user ISRs need not bother about that.<br />
<br />
====Multicore support (MPC5668 and MPC5643L)====<br />
* Functions used for multicore support on MPC5668 (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5668/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5668/inc/ee_dual.h]</tt> for prototypes and other details):<br />
** EE_mpc5668_start_z0(f): Enable the z0 CPU.<br />
<br />
The same paradigm of multicore support available for MPC5668G, is also available for the MPC5643L, (for details see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5643l/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5643l/inc/ee_dual.h]</tt>). Likewise MPC5668G, in order to start the slave core, a EE_mpc5643l_start_slave(f) call has to be provided at startup (typically in main function) immediately before the StartOS().<br />
<br />
=== Boards ===<br />
* ERIKA has been developed on an '''Axiom MPC5674evbfxmb evaluation board'''. This evaluation board has the MAMBA microcontroller (Freescale MPC5674F)<br />
** The kernel has no dependency on the board itself, but some of its functionalities can be used for debugging purposes. Including file "pkg/board/axiom_mpc5674fxmb/inc/ee_board.h" the following functions can be used:<br />
*** EE_leds_init(): which sets up the GPIOs associated with the leds.<br />
*** EE_EE_leds(mask): which turns the i-th led on or off depending on the state of the i-th bit in the mask passed as an argument.<br />
*** EE_led_<X>_on()/EE_led_<X>_off(): turns led X on or off.<br />
*** EE_buttons_disable_interrupts(button): disables the interrupt associated to the given button.<br />
*** EE_buttons_enable_interrupts(button): enables it.<br />
*** EE_buttons_clear_ISRflag(button): acknowledges the interrupt coming from the given button.<br />
*** EE_button_get_B<X>(): gets the status of button X.<br />
*** EE_buttons_init(): initializes the GPIOs associated to buttons.<br />
** The functions above are available if, respectively, __USE_LEDS__ and __USE_BUTTONS__ are defined upon inclusion of ee_board.h<br />
** The connections are assumed to be the following:<br />
*** GPIO 147-150: connected to LED0-3. Looking at the pins on the EVB:<br />
**** ETPUB1 -> USER_LED1<br />
**** ETPUB2 -> USER_LED2<br />
**** ETPUB3 -> USER_LED3<br />
*** GPIO 450: connected to BUTTON0 (ETPUC9 -> USER_DEV1)<br />
<br />
* Erika is available for the '''Freescale MPC5668EVB Evaluation Board'''. This evaluation board has the FADO microcontroller (Freescale MPC5668G)<br />
** for this board the are no available support for leds or buttons.<br />
<br />
* Erika is available for '''Freescale MPC564xLEVB Evaluation Board'''. This evaluation board has the LEOPARD microcontroller (Freescale MPC5643L)<br />
** for this board there is the same set of primitives defined for "Axiom MPC5674evbfxmb" board, hence a basic support for leds and button is available.<br />
<br />
== Multicore support ==<br />
<br />
In the ERIKA multicore support for PPC e200 there are a few aspects specific to the PPC e200 architecture, and they are described here. Please refer to [[ERIKA multicore support]] for general information on ERIKA multicore systems.<br />
<br />
The PPC evaluation board supported by Erika Multicore is the Freescale MPC5668G/E Evaluation kit, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5668GKIT. The multicore support is also provided for MPC5643L with the Freescale evaluation board MPC564xL EVB, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=XKT564L.<br />
<br />
In multicore configuration, is it possible running both instances of the operating system both in RAM and Flash. For instance on MPC5668G, the internal SRAM is partitioned statically in two: memory from 0x40000000 to 0x4001FFFF is reserved to the first core and shared variables, while memory from 0x40020000 to 0x4003FFFF is reserved to the second core. 0x40020000 is used as the starting address of the second core. A similar approach is available for MPC5643L. In order to customize such memory assignments please refer to memory0.ld and memory1.ld files in "erika/pkg/mcu/freescale_mpc56XX/cfg/multicore" (where XX=43l for Leopard and XX=68 for Fado).<br />
<br />
Shared variable data is allocated in a single section (<tt>.mcglobald</tt>). Access to this section must be performed without cache, or the OS may malfunction. ERIKA crt0 does not enable cache; if you want to enable it, you should also make sure that the <tt>.mcglobald</tt> section is allocated on a page on its own by the linker script, and that the MMU is configured to mark such page as non-cached. <br />
<br />
The OS uses two software interrupts (6 and 7) and two hardware semaphores (0 and 1) of the MPC5668G to handle inter-core communication. They are initialised inside <code>StartOS()</code>. While all the other software interrupts and semaphores are available for user applications, those used by the OS should not be meddled with by user code. It is okay to briefly mask the interrupts with higher-priority interrupts or by disabling interrupts. In case of MPC5643L, as the microcontroller has two different interrupt controllers (one for each core), SW interrupt number 7 is used for both cores. Even if the MPC5643L has two SEMA4 modules, only the first module (the one associated to the master core) is used for this mechanism, this means that semaphores 0 and 1 of the first SEMA4 module are used for synchronisation (as in MPC5668G), while the remaining semaphores of the first SEMA4 module and all semaphores belonging to the second SEMA4 module are available for user applications.<br />
<br />
Examples of multicore applications are in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/ examples/ppc/dual_examples]</tt>. In particular, <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/mono_activate01/ examples/ppc/dual_examples/mono_activate01]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/multi_event01/ examples/ppc/dual_examples/multi_event01]</tt> are complete applications, nearer to real-world usage.<br />
<br />
Erika multicore for PowerPC supports AUTOSAR OS-like functionalities. For details please see the following page (but take into account that these features have not been published yet):<br />
[[Erika AUTOSAR OS]]<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for PPC e200 produces a Lauterbach Trace32 configuration file (<tt>t32.cmm</tt>) and a ORTI description file (<tt>system.orti</tt>) inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger, please issue <code>t32mppc</code> from the output directory. The ERIKA build system honors the <tt>T32SYS</tt> environment variable, if set.<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named <tt>start.sh</tt>) is produced in the output directory. To run the debugger, please issue <code>start.sh</code> from the output directory. The script creates two instances of the debugger, one for each core. For instace when MPC5668G is turned on, only the first (Z6) core is enabled. In order to simulate the real setup, the debugger connected to the second (Z0) core does not enable its core, but it is responsibility of the code running on the Z6 core to enable the Z0 core (this is different from the example script for MPC5668G distributed with the Lauterbach Trace32 software). Nonetheless, the startup script loads all the code and the debug symbols for both core and both debugger instances. In a typical debugging session, you start the execution of the code on the Z6 core from its debugger, and then, when the Z0 core has become active, start also the code on the Z0 core from the Z0 debugger. The barrier inside <code>StartOS()</code> comes handy to synchronize the code running on the two cores. The <tt>start.sh</tt> script runs only on Linux; currently the ERIKA build system does not support Windows to run Trace32 for e200 multicore systems. A similar approach has been adopted for MPC5643L.<br />
<br />
==Internals==<br />
<br />
===Interrupts===<br />
<br />
Interrupt handling in PPC e200 ERIKA uses software vector mode and a single entry point for all interrupts and exceptions, which is <code>EE_e200z7_irq()</code>. This function calls the user ISR and issues the end-of-interrupt for external interrupts; when the served interrupt is not nested, i.e., it interrupted a task directly, <code>EE_e200z7_irq()</code> also calls the scheduler before returning.<br />
<br />
This scheme of IRQ handling can be changed by rewriting the crt0 and changing the IVOR setup. In this way it is possible, for example, to use hardware vector mode. Please note that it is important that the end-of-interrupt be issued before calling the scheduler, as the scheduler may not return when a new task is to be scheduled.<br />
<br />
===Use of non volatile registers in Erika PowerPC===<br />
<br />
Some Erika RTOS assembly modules in PowerPC use non volatile registers for their internal purposes (r14-r31). Such modules are:<br />
<br />
* ee_e200zx_contex.S - This module is in charge of managing context switch for multistack on e200zx. In this module r14-r31 are saved and restored in a prologue and epilogue;<br />
* ee_oo.S - This module is in charge of saving and restoring registers for Osek TerminateTask() on e200zx. In this module r14-r31 are saved and restored in a prologue and epilogue;<br />
* ee_entry.S - This module handles exception entry points and hardware setup for the e200zx. In this module the istruction stmw uses r28-r30 to initialize SRAM. This code is stripped if a custom ISR table is used (see XXX for details);<br />
* ee_boot.S - This module represents boot sequence for PowerPC MCUs. The erika boot sequence accesses non volatile registers in init phase. This code can be removed from build process by using XXXX.<br />
<br />
The use of r14-r31 registers is limited, just few lines of code. But this information is relevant in case advanced features of some compilers are used, (e.g.: to define additional non-standard SDAs, Small Data Area). For instance Windriver Diab compiler has the REGISTER directive in the linker script to fullfill this requirement. If this non-standard approach is not required this information can be neglected. It is provided in order to give the position of such code whenever the use of non volatile registers (r14-r31) is necessary for non-standard purposes. For details please refere to your compiler documentation.<br />
<br />
'''Assumption for future development:''' additional SDA base addresses will be stored starting from register r14<br />
<br />
== Download and install of Eclipse, RT-Druid, and ERIKA source ==<br />
<br />
To build an ERIKA application you need:<br />
* ERIKA source code<br />
* RT-Druid and a hosting Eclipse<br />
* Some command-line tools<br />
<br />
=== ERIKA source code ===<br />
<br />
ERIKA source code is bundled with RT-Druid. ERIKA for PPC e200 honors the definition of '''ERIKA_FILES''', so you can use the latest version of ERIKA as explained in [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]].<br />
<br />
=== Eclipse and RT-Druid in one piece ===<br />
<br />
A complete version of an Eclipse installation together with the RT-Druid plugin can be downloaded from this page:<br />
http://erika.tuxfamily.org/erika-for-multiple-devices.html. Please make sure to use a version not older than 1.6.0 beta. See also [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application]].<br />
<br />
=== Eclipse and RT-Druid piece by piece ===<br />
<br />
Alternatively, if you already have a copy of Eclipse or you want to use a version of Eclipse different from the one provided by the page above, you can follow this procedure.<br />
* To download the e200 plug-in for Eclipse refer the following site: [http://download.tuxfamily.org/erika/webdownload/rtdruid_beta Plug-in download site].<br />
Procedure for installation:<br />
* Step 0:<br />
: Get ''Eclipse'' and required plug-ins;<br />
: Where possible, the suggestion is to download the ''all in one update site'' and use the eclipse update manager or to use the eclipse update manager directly on a web site;<br />
:* Eclipse<br />
:: If you don't have any eclipse installations, you can download eclipse with cdt already installed from [http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/heliossr1 Eclipse IDE for C/C++].<br />
:: It is also possible use an already installed distribution of eclipse or to download one (for example from [http://www.eclipse.org/downloads Eclipse Downloads]) and then add all missing plug-ins.<br />
:* EMF<br />
:: The main page to download EMF is [http://www.eclipse.org/modeling/emf/downloads/?project=emf Eclipse Modeling Framework].<br />
:: The version to download is related to the eclipse version: eclipse 3.3 -> emf 2.3 , eclipse 3.4 -> emf 2.4, eclipse 3.5 -> emf 2.5, eclipse 3.6 -> emf 2.6. <br />
:: The list of required plugins is:<br />
::: org.eclipse.emf.common<br />
::: org.eclipse.emf.ecore<br />
::: org.eclipse.emf.edit<br />
::: org.eclipse.emf.common.ui<br />
::: org.eclipse.emf.edit.ui<br />
:: Clearly it is possible to install more plugins, like the whole emf runtime or sdk<br />
:* CDT<br />
:: The main page to download CDT is [http://www.eclipse.org/cdt/downloads.php CDT Downloads].<br />
:: Also here, the version to download is related to eclipse version. <br />
:: In this case is required only the cdt runtime plugin.<br />
: [http://erika.tuxfamily.org/forum/viewtopic.php?f=6&t=651&sid=89784e2d97765c3f1c41f6e3c049437a#p727 Forum Post (in italian) about installing the Eclipse plugins]<br />
* Step 1:<br />
: Open ''Eclipse'';<br />
: From the menu ''Help'' select ''Install New Software...'';<br />
: Add with the button ''Add...'' the reference site mentioned above (fill the Location field with this: http://download.tuxfamily.org/erika/webdownload/rtdruid_beta);<br />
: Tick all plug-ins related to RT-Druid core and to Erika Enterprise, then click on the button ''Next'' to install them;<br />
: Restart Eclipse;<br />
* Step 2:<br />
: From the menu ''File'' select ''New'' and then RT-Druid Oil and C/C++ Project;<br />
: From the Project menu select one of the available e200 demo tests;<br />
: Then click on the project name with the right mouse button and build to obtain the elf object module for debugging;<br />
<br />
=== Additional software ===<br />
<br />
ERIKA uses GNU make and some command-line utilities to build programs. You need the following tools (please notice that only the less common commands are listed here; very common commands that are present in any Unix/POSIX system like ''ls'' are not listed for simplicity):<br />
* make (GNU version)<br />
* gawk (GNU AWK)<br />
* sed<br />
* grep<br />
<br />
For Linux the above commands are present in virtually every standard installation; but you can always install them from the respective packages of your distributions.<br />
<br />
For Windows, [http://www.cygwin.com/ Cygwin] is recommended. Please make sure to include the above packages (package names are the same as the tool names).<br />
<br />
== HOWTOs ==<br />
* [[How to create, compile and debug an application for Freescale MPC5674F]]<br />
* [[How to run the MODISTARC regression tests for Freescale MPC5674F]]<br />
<br />
<br />
[[Category:Supported Devices]]</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Freescale_PPC_e200_(MPC_56xx)Freescale PPC e200 (MPC 56xx)2014-07-17T09:51:47Z<p>Francesco: /* Use of non volatile registers in Erika PowerPC */</p>
<hr />
<div>= Freescale PPC e200 (MPC 56xx) support =<br />
ERIKA Enterprise supports the PPC e200 family microcontrollers.<br />
The support for RT-Druid is available starting from release 1.5.0.<br />
The support includes: <br />
# Support MPC5674F (e200z7). MPC5668G (e200z6) is supported in version 1.6.0; version 1.6.1 will support both cores (z6 and z0) of the MPC5668G (already available on the [[ERIKA Enterprise and RT-Druid SVN Access|Subversion repository]]). Support for MPC5643L (e200z4).<br />
# Support for the WindRiver DIAB and Freescale CodeWarrior compilers.<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers<br />
** WindRiver DIAB C Compiler 5.5.1 and 5.8.0.<br />
** Freescale CodeWarrior:<br />
*** Windows: CodeWarrior Development Studio for MPC55xx/56xx 2.7<br />
*** Linux: CodeWarrior Development Studio for MCU 10.2<br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: Currently limited to the MPC5668G and MPC5643L, it follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ Autosar]: two instances of the operating systems run on the two cores, and communication between cores is performed with a few APIs and shared memory.<br />
<br />
* MMU Handling<br />
** Static global mappings to let all the application see all the memory/peripherals in the system; no memory protection is implemented and all the code is executed in supervisor mode.<br />
<br />
== Host Configuration ==<br />
<br />
* RT-Druid requires Java 1.6.<br />
* It is possible to use a version of ERIKA more recent than the one provided with RT-Druid; just download the ERIKA tree from the repository (see [[ERIKA Enterprise and RT-Druid SVN Access]]) and point the '''ERIKA_FILES''' environment variable to its location; see [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]] for some caveats.<br />
<br />
=== Wind River Diab ===<br />
* Compiler: The compiler commands (dcc, das, dld, and dar) are assumed to be reachable from the $PATH. If a specific version of them has to be used it must be specified in pkg/cfg/arch/cc_z7diab.mk<br />
* Operating system: The PPC e200 port has been developed under Debian testing/unstable as of May 2010; the only known requirement is Java 1.6 to run RT-Druid.<br />
* In the reference environment, the Diab toolchain was located in /opt/case/diabdata/<version> and Eclipse in /opt/eclipse. No hard requirement is made by the build system, as specified above. <br />
<br />
=== Freescale CodeWarrior ===<br />
*Compiler: The compiler directory can be specified using the environment variable '''PPC_CW_BASEDIR'''; this directory must contain the directories ''PA_Support'', and ''PA_Tools'' or ''PowerPC_EABI_Tools''. ERIKA makefiles find all the files they need with relatives paths from there. Please notice that makefiles require that the variable '''PPC_CW_BASEDIR''' do not contain any space. An evaluation or a limited version of the compiler can be downloaded from the [http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_DOWNLOADS Freescale Web site].<br />
*Operating system: both Linux and Windows are supported. CodeWarrior support has been developed under Debian Linux and Windows XP, but other (and more recent) versions should work. On Windows, ''Special Edition: CodeWarrior for Microcontrollers 10.5'' is currently used, and on Linux ''CodeWarrior Development Studio for MCU'' version 10.2. On Windows the Cygwin environment is used for ERIKA makefiles, so the '''PPC_CW_BASEDIR''' variable must use forward slashes '/' and must not contain spaces; you can always convert the path with the ''cygpath'' command. For example, in this case the value to use is <code>/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7</code>:<br />
$ cygpath.exe `cygpath.exe -ms "/c/Program Files/Freescale/CW for MPC55xx and MPC56xx 2.7"`<br />
/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7<br />
*OIL file: Currently, an ''EEOPT'' with value '''"__CODEWARRIOR__"''' must be specified in the OIL file. See [[#OIL file configuration]] for more details.<br />
<br />
== Target configuration and programming==<br />
<br />
* ERIKA is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]<br />
* ERIKA supports the Freescale MPC5674F, MPC5668G and MPC5643L MCUs (we have been able to run it on an MPC56XX and others; Freescale MCUs are really very similar).<br />
* At system boot the interrupt controller is set up to work in Software Vector Mode, and all the interrupts are associated to default handlers. The kernel does not use any specific device/interrupts, although for testing purposes it is possible to use the decrementer and some gpios as interrupt sources. All the code is executed from flash, all the data sections are loaded into the SRAM at boot time (the MMU is configured to provide 1:1 mappings for code running in system mode for all the sensible regions, like flash, sram and device registers).<br />
* The version in the repository supports both FLE and VLE modes.<br />
* The scripts generated by the build process are compatible with Lauterbach v200912. The commands generated to setup the NEXUS port are not compatible with older releases of the Lauterbach software. In case you hit this problem, remove the NEXUS.* lines from the generated scripts, ad set up the port according to the Lauterbach version you are using.<br />
* Target registers are used according the PPC ABI described in the DIAB manual.<br />
* The stack fill pattern is configurable at compile time, but is assumed to be 0xa5.<br />
* For Osek conformance classes, which support TerminateTask(), each running task requires 96 bytes of stack. <br />
For multistack configurations, 76 bytes are required on each stack for context switching. You can add this numbers to the requirements of your application to estimate task usage.<br />
* Stack pointer is aligned at 16 byte (fixed in version 1.6)<br />
<br />
=== MCUs ===<br />
* The MCUs supported are currently the following:<br />
** MPC5674F (Mamba)<br />
** MPC5668G (Fado)<br />
** MPC5643L (Leopard)<br />
<br />
===OIL file configuration===<br />
For more information about configuration through OIL file, see [[Tutorial: RT-Druid and OIL basics]]. Here only the e200zX-specific part of OIL is described.<br />
;CPU (CPU_DATA)<br />
: CPU must be set to E200ZX. The exact model is specified with the '''MODEL''' item (supported values are '''E200Z0''', '''E200Z6''' , '''E200Z7''' and '''E200Z4'''. Generation of VLE code can be selected by setting '''VLE''' to '''TRUE'''; please notice that all the application and the OS code must have the same setting, as ERIKA makefiles do not support mixed programs. Size in byte of the shared stack can be specified with the optional '''SYS_STACK_SIZE''' item.<br />
: Example of a CPU_DATA section:<br />
CPU_DATA = PPCE200ZX {<br />
ID = "MainCpu";<br />
MODEL = E200Z7;<br />
APP_SRC = "main.c";<br />
MULTI_STACK = FALSE;<br />
VLE = FALSE;<br />
SYS_STACK_SIZE = 512;<br />
};<br />
:On multicore systems, one CPU_DATA instance can exist for each core. They must have different '''ID'''s. See [[ERIKA multicore support]] for more details about multicore systems on Erika.<br />
;MCU<br />
: MCU support is present for MPC5674F ,MPC5668G and MPC5643L. The only item supported is '''MODEL''', which can be either '''MPC5674F''', '''MPC5668G''' or '''MPC5643L'''. Most of the differences produced by this setting affect memory map and Lauterbach scripts.<br />
: Example:<br />
MCU_DATA = PPCE200ZX {<br />
MODEL = MPC5674F;<br />
};<br />
;System Timer<br />
Erika on PowerPC has a system timer based on PowerPC Decrementer. This feature is available for all supported MCUs: MPC5674F (Mamba), MPC5668G(Fado) and MPC5643L (Leopard). System time also requires CPU_CLOCK field to be set on CPU_DATA, hence CPU_CLOCK value must be added in CPU_DATA configuration to have a system timer configured.<br />
This is an example to configure Decrementer as System Timer:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_DECREMENTER";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "DECREMENTER";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
<br />
Furthermore for MPC5643L (Leopard) is available a system timer based on Freescale STM (System Timer Module), that is a device available in several Freescale PowerPC MCUs. In this case the following configuration must be take into account:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_STM";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
...<br />
...<br />
<br />
<br />
;EEOPTs<br />
: See also [[EEOPT]] for common EEOPTs.<br />
: Special options for the PPC e200 ERIKA porting can be specified through '''EE_OPT''' items in the '''OS''' section (please notice that the value for an '''EE_OPT''' is a string, so double quotes (") must be added around the values in this list.<br />
:; EE_SYSTEM_TIMER_DEVICE_DECREMENTER (see system timer section above)<br />
:; EE_SYSTEM_TIMER_DEVICE_STM (available only for MPC5643L, see system timer section above)<br />
:;EE_ISR_DYNAMIC_TABLE<br />
::Used to enable dynamic ISR table support that let register ISR handlers at runtime calling <code>EE_e200z7_register_ISR</code>.<br />
:;__E200ZX_EXECUTE_FROM_RAM__<br />
:: When specified, a linker script is used that maps both code and data in the RAM space. Executables produced with this option can be used only together with a debugger that loads the program in memory. By default, code and constant data are mapped to Flash, data to RAM.<br />
:;__CODEWARRIOR__<br />
:: Invoke Freescale CodeWarrior compiler. See [[#Freescale CodeWarrior]] for information on how to configure the compiler. The default compiler is Wind River Diab; see [[#Wind River Diab]] for configuration.<br />
:;__USE_CUSTOM_LINKER_SCRIPT__<br />
:: Don't use the dafault linker script. Users can direct the linker to use their own linker script by setting the <code>LDFLAGS</code> variable. Example:<br />
OS EE {<br />
EE_OPT = "__USE_CUSTOM_LINKER_SCRIPT__";<br />
LDFLAGS = "../my_linker_script.ld";<br />
};<br />
:;__USE_CUSTOM_CRT0__<br />
:: Don't use Erika default crt0. Users can provide their own crt0 by adding source files in the usual way (APP_SRC in the OIL file).<br />
;;__MINIMAL_CC_OPTIONS__<br />
:: Enable only the compiler flags absolutely needed to compile Erika, so users can easily add their preferences in CFLAGS.<br />
;;__EE_USE_MMU__<br />
:: Enable the MMU support. The MMU can be configured by calling <code>EE_e200zx_mmu_setup()</code>. See the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> for more details. An example configuration can be found in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt>.<br />
;;__EE_CRT0_INIT_MMU__<br />
:: Initialize the MMU from the crt0. See <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt> for an example, and the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt>.<br />
;;EE_NO_LIBEE<br />
:: To not generete the kernel library '''libee.a''' but link all the objects files (kernel + application) directly in an elf file. This option is useful to try Erika with CodeWarrior compiler with an evaluation license, because the archiver is not enabled with this license.<br />
;;DEBUG<br />
:: On this architecture, enabling debug symbols does not inhibit optimization.<br />
;;MPC5643L_STD_SW_MMU_CONFIG"<br />
:: This EE_OPT is valid only for MPC5643L (Leopard) and provides a standard (and in most cases sufficient) MMU configuration. This option is useful expecially running your code from FLASH where Debugger does not initializes the MMU for you.<br />
;;EE_LAUTERBACH_DEMO_SIM<br />
:: This option is available only for Mamba (MPC5674F), for details please take a look at DEMO_ErikaSim in the directory of templates. It causes the generation of Lauterbach scripts to use with Lauterbach simulator.<br />
<br />
There are a few examples in the ERIKA code base that can be used as a starting point for new projects. Examples include also a makefile, which can be used to compile a project without a need of an IDE. The makefile runs RT-Druid non-interactively, and requires the environment variable '''RTDRUID_ECLIPSE_HOME''' to point to the Eclipse directory where RT-Druid is installed.<br />
<br />
Examples can be accessed as templates in RT-Druid (see [[How to create, compile and debug an application for Freescale MPC5674F]]), or directly in the source code: [http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/ examples/ppc/].<br />
<br />
In the first version of ERIKA and RT-Druid supporting e200zX, the only e200-specific setting in the OIL configuration file was the CPU_DATA value, which had to be set to '''MPC5674F''' instead of '''PPCE200ZX'''. This not supported any more.<br />
<br />
=== APIs ===<br />
* List of functions (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_irq.h?view=markup pkg/cpu/e200zx/inc/ee_irq.h]</tt> for prototypes and other details):<br />
** EE_e200z7_register_ISR(level, handler, priority): Associate <tt>handler</tt> to the IRQ <tt>level</tt>, with the given <tt>priority</tt> (available only if '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' is set).<br />
** EE_e200z7_setup_decrementer(delay): Configure the decrementer to raise an interrupt every <tt>delay</tt> cycles.<br />
** EE_e200z7_setup_decrementer_oneshot(delay): Configure the decrementer to raise an interrupt <tt>delay</tt> cycles after invocation.<br />
** EE_e200z7_stop_decrementer(): Stop the decrementer from generating interrupts.<br />
** EE_e200zx_setup_fixed_intv(bitpos): Enable the fixed-interval interrupt.<br />
** EE_e200zx_stop_fixed_intv(): Disable the fixed-interval interrupt.<br />
** EE_e200zx_mmu_setup(entries, count): MMU initialization.<br />
<br />
Note: notice that the *_e200z7_* is slightly misleading since it seem to refer only to e200z7 family, it is a legacy name convention when the only supported architecture by Erika was Z7. Currently even Z0, Z4 and Z6 are supported hence these functions can be used for such architectures, although it refers to *_e200z7_*.<br />
<br />
====Interrupts====<br />
<br />
There are two way to configure ISR. The standard way is the static way with OIL configuration (example):<br />
<br />
ISR DecrIsr {<br />
CATEGORY = 2;<br />
ENTRY = "DECREMENTER";<br />
};<br />
<br />
ISR FixedIntvIsr {<br />
CATEGORY = 2;<br />
ENTRY = "FIXED_INTV";<br />
HANDLER = "fixed_intv_handler";<br />
};<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
ENTRY = "0";<br />
};<br />
ISR IsrMedium {<br />
CATEGORY = 2;<br />
PRIORITY = 2;<br />
ENTRY = "1";<br />
};<br />
<br />
ISR IsrHigh {<br />
CATEGORY = ;<br />
PRIORITY = 3;<br />
ENTRY = "2";<br />
HANDLER = "isr_high_handler";<br />
};<br />
<br />
In static ISR table handling mode there's full support for both ISR1 and ISR2 for '''external interrupt'''. To register an handler you should use the suitable macro ('''ISR1''' or '''ISR2''') passing the value of '''HANDLER''' field or the '''ISR name''', in case the former is missing. The configuration field '''ENTRY''' declare the position of the handler inside the vector table (the example show three handlers that get the first three positions in vector, corrisponding to the first three software interrupt request). Priority field corripsond to interrupt priority value set to corrisponding Interrupt Controller Priority select registers ('''INTC.PSR[(ENTRY)] = PRIORITY'''), the values have to be inside [0..15] range.<br />
<br />
There is direct support for two cpu '''internal exceptions''', those generated by the time base facilities: decrementer and fixed interval timer ('''ENTRY = "DECREMENTER"''' and '''ENTRY = "FIXED_INTV"'''' respectively.). Support for Watch-Dog timer will be added. To register an handler for internal interrupt you have to use '''ISR1_INT''' or '''ISR2_INT''' (two different couple of macros are needed to issue EOI, End Of Interrupt, only for external interrupts). Priority field in configuration have no meaning for internal interrupts.<br />
<br />
You can register handler by code dinamically with with the <code>EE_e200z7_register_ISR()</code> described above. To enable dynamic ISR table support you must declare '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' configuration OIL file. The '''first 16 level''' of dynamic table are reserved for '''internal exceptions''' handlers, so you have to add this offset to the '''ENTRY''' value of the static approach to register an handler to the same interrupt source.<br />
<br />
ISRs (Interrupt Service Routines) are just void functions with no arguments. For external interrupts (IVOR4), the EOI (End Of Interrupt) is issued by ERIKA's handler; user ISRs need not bother about that.<br />
<br />
====Multicore support (MPC5668 and MPC5643L)====<br />
* Functions used for multicore support on MPC5668 (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5668/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5668/inc/ee_dual.h]</tt> for prototypes and other details):<br />
** EE_mpc5668_start_z0(f): Enable the z0 CPU.<br />
<br />
The same paradigm of multicore support available for MPC5668G, is also available for the MPC5643L, (for details see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5643l/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5643l/inc/ee_dual.h]</tt>). Likewise MPC5668G, in order to start the slave core, a EE_mpc5643l_start_slave(f) call has to be provided at startup (typically in main function) immediately before the StartOS().<br />
<br />
=== Boards ===<br />
* ERIKA has been developed on an '''Axiom MPC5674evbfxmb evaluation board'''. This evaluation board has the MAMBA microcontroller (Freescale MPC5674F)<br />
** The kernel has no dependency on the board itself, but some of its functionalities can be used for debugging purposes. Including file "pkg/board/axiom_mpc5674fxmb/inc/ee_board.h" the following functions can be used:<br />
*** EE_leds_init(): which sets up the GPIOs associated with the leds.<br />
*** EE_EE_leds(mask): which turns the i-th led on or off depending on the state of the i-th bit in the mask passed as an argument.<br />
*** EE_led_<X>_on()/EE_led_<X>_off(): turns led X on or off.<br />
*** EE_buttons_disable_interrupts(button): disables the interrupt associated to the given button.<br />
*** EE_buttons_enable_interrupts(button): enables it.<br />
*** EE_buttons_clear_ISRflag(button): acknowledges the interrupt coming from the given button.<br />
*** EE_button_get_B<X>(): gets the status of button X.<br />
*** EE_buttons_init(): initializes the GPIOs associated to buttons.<br />
** The functions above are available if, respectively, __USE_LEDS__ and __USE_BUTTONS__ are defined upon inclusion of ee_board.h<br />
** The connections are assumed to be the following:<br />
*** GPIO 147-150: connected to LED0-3. Looking at the pins on the EVB:<br />
**** ETPUB1 -> USER_LED1<br />
**** ETPUB2 -> USER_LED2<br />
**** ETPUB3 -> USER_LED3<br />
*** GPIO 450: connected to BUTTON0 (ETPUC9 -> USER_DEV1)<br />
<br />
* Erika is available for the '''Freescale MPC5668EVB Evaluation Board'''. This evaluation board has the FADO microcontroller (Freescale MPC5668G)<br />
** for this board the are no available support for leds or buttons.<br />
<br />
* Erika is available for '''Freescale MPC564xLEVB Evaluation Board'''. This evaluation board has the LEOPARD microcontroller (Freescale MPC5643L)<br />
** for this board there is the same set of primitives defined for "Axiom MPC5674evbfxmb" board, hence a basic support for leds and button is available.<br />
<br />
== Multicore support ==<br />
<br />
In the ERIKA multicore support for PPC e200 there are a few aspects specific to the PPC e200 architecture, and they are described here. Please refer to [[ERIKA multicore support]] for general information on ERIKA multicore systems.<br />
<br />
The PPC evaluation board supported by Erika Multicore is the Freescale MPC5668G/E Evaluation kit, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5668GKIT. The multicore support is also provided for MPC5643L with the Freescale evaluation board MPC564xL EVB, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=XKT564L.<br />
<br />
In multicore configuration, is it possible running both instances of the operating system both in RAM and Flash. For instance on MPC5668G, the internal SRAM is partitioned statically in two: memory from 0x40000000 to 0x4001FFFF is reserved to the first core and shared variables, while memory from 0x40020000 to 0x4003FFFF is reserved to the second core. 0x40020000 is used as the starting address of the second core. A similar approach is available for MPC5643L. In order to customize such memory assignments please refer to memory0.ld and memory1.ld files in "erika/pkg/mcu/freescale_mpc56XX/cfg/multicore" (where XX=43l for Leopard and XX=68 for Fado).<br />
<br />
Shared variable data is allocated in a single section (<tt>.mcglobald</tt>). Access to this section must be performed without cache, or the OS may malfunction. ERIKA crt0 does not enable cache; if you want to enable it, you should also make sure that the <tt>.mcglobald</tt> section is allocated on a page on its own by the linker script, and that the MMU is configured to mark such page as non-cached. <br />
<br />
The OS uses two software interrupts (6 and 7) and two hardware semaphores (0 and 1) of the MPC5668G to handle inter-core communication. They are initialised inside <code>StartOS()</code>. While all the other software interrupts and semaphores are available for user applications, those used by the OS should not be meddled with by user code. It is okay to briefly mask the interrupts with higher-priority interrupts or by disabling interrupts. In case of MPC5643L, as the microcontroller has two different interrupt controllers (one for each core), SW interrupt number 7 is used for both cores. Even if the MPC5643L has two SEMA4 modules, only the first module (the one associated to the master core) is used for this mechanism, this means that semaphores 0 and 1 of the first SEMA4 module are used for synchronisation (as in MPC5668G), while the remaining semaphores of the first SEMA4 module and all semaphores belonging to the second SEMA4 module are available for user applications.<br />
<br />
Examples of multicore applications are in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/ examples/ppc/dual_examples]</tt>. In particular, <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/mono_activate01/ examples/ppc/dual_examples/mono_activate01]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/multi_event01/ examples/ppc/dual_examples/multi_event01]</tt> are complete applications, nearer to real-world usage.<br />
<br />
Erika multicore for PowerPC supports AUTOSAR OS-like functionalities. For details please see the following page (but take into account that these features have not been published yet):<br />
[[Erika AUTOSAR OS]]<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for PPC e200 produces a Lauterbach Trace32 configuration file (<tt>t32.cmm</tt>) and a ORTI description file (<tt>system.orti</tt>) inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger, please issue <code>t32mppc</code> from the output directory. The ERIKA build system honors the <tt>T32SYS</tt> environment variable, if set.<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named <tt>start.sh</tt>) is produced in the output directory. To run the debugger, please issue <code>start.sh</code> from the output directory. The script creates two instances of the debugger, one for each core. For instace when MPC5668G is turned on, only the first (Z6) core is enabled. In order to simulate the real setup, the debugger connected to the second (Z0) core does not enable its core, but it is responsibility of the code running on the Z6 core to enable the Z0 core (this is different from the example script for MPC5668G distributed with the Lauterbach Trace32 software). Nonetheless, the startup script loads all the code and the debug symbols for both core and both debugger instances. In a typical debugging session, you start the execution of the code on the Z6 core from its debugger, and then, when the Z0 core has become active, start also the code on the Z0 core from the Z0 debugger. The barrier inside <code>StartOS()</code> comes handy to synchronize the code running on the two cores. The <tt>start.sh</tt> script runs only on Linux; currently the ERIKA build system does not support Windows to run Trace32 for e200 multicore systems. A similar approach has been adopted for MPC5643L.<br />
<br />
==Internals==<br />
<br />
===Interrupts===<br />
<br />
Interrupt handling in PPC e200 ERIKA uses software vector mode and a single entry point for all interrupts and exceptions, which is <code>EE_e200z7_irq()</code>. This function calls the user ISR and issues the end-of-interrupt for external interrupts; when the served interrupt is not nested, i.e., it interrupted a task directly, <code>EE_e200z7_irq()</code> also calls the scheduler before returning.<br />
<br />
This scheme of IRQ handling can be changed by rewriting the crt0 and changing the IVOR setup. In this way it is possible, for example, to use hardware vector mode. Please note that it is important that the end-of-interrupt be issued before calling the scheduler, as the scheduler may not return when a new task is to be scheduled.<br />
<br />
===Use of non volatile registers in Erika PowerPC===<br />
<br />
Some Erika RTOS assembly modules in PowerPC use non volatile registers for their internal purposes (r14-r31). Such modules are:<br />
<br />
* ee_e200zx_contex.S - This module is in charge of managing context switch for multistack on e200zx<br />
* ee_oo.S - This module is in charge of saving and restoring registers for Osek TerminateTask() on e200zx<br />
* ee_entry.S - This module handles exception entry points and hardware setup for the e200zx<br />
* ee_boot.S - This module represents boot sequence for PowerPC MCUs.<br />
<br />
The use of r14-r31 registers is limited, just few lines of code. But this information is relevant in case advanced features of some compilers are used, (e.g.: to define additional non-standard SDAs, Small Data Area). For instance Windriver Diab compiler has the REGISTER directive in the linker script to fullfill this requirement. If this non-standard approach is not required this information can be neglected. It is provided in order to give the position of such code whenever the use of non volatile registers (r14-r31) is necessary for non-standard purposes. For details please refere to your compiler documentation.<br />
<br />
'''Assumption for future development:''' additional SDA base addresses will be stored starting from register r14<br />
<br />
== Download and install of Eclipse, RT-Druid, and ERIKA source ==<br />
<br />
To build an ERIKA application you need:<br />
* ERIKA source code<br />
* RT-Druid and a hosting Eclipse<br />
* Some command-line tools<br />
<br />
=== ERIKA source code ===<br />
<br />
ERIKA source code is bundled with RT-Druid. ERIKA for PPC e200 honors the definition of '''ERIKA_FILES''', so you can use the latest version of ERIKA as explained in [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]].<br />
<br />
=== Eclipse and RT-Druid in one piece ===<br />
<br />
A complete version of an Eclipse installation together with the RT-Druid plugin can be downloaded from this page:<br />
http://erika.tuxfamily.org/erika-for-multiple-devices.html. Please make sure to use a version not older than 1.6.0 beta. See also [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application]].<br />
<br />
=== Eclipse and RT-Druid piece by piece ===<br />
<br />
Alternatively, if you already have a copy of Eclipse or you want to use a version of Eclipse different from the one provided by the page above, you can follow this procedure.<br />
* To download the e200 plug-in for Eclipse refer the following site: [http://download.tuxfamily.org/erika/webdownload/rtdruid_beta Plug-in download site].<br />
Procedure for installation:<br />
* Step 0:<br />
: Get ''Eclipse'' and required plug-ins;<br />
: Where possible, the suggestion is to download the ''all in one update site'' and use the eclipse update manager or to use the eclipse update manager directly on a web site;<br />
:* Eclipse<br />
:: If you don't have any eclipse installations, you can download eclipse with cdt already installed from [http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/heliossr1 Eclipse IDE for C/C++].<br />
:: It is also possible use an already installed distribution of eclipse or to download one (for example from [http://www.eclipse.org/downloads Eclipse Downloads]) and then add all missing plug-ins.<br />
:* EMF<br />
:: The main page to download EMF is [http://www.eclipse.org/modeling/emf/downloads/?project=emf Eclipse Modeling Framework].<br />
:: The version to download is related to the eclipse version: eclipse 3.3 -> emf 2.3 , eclipse 3.4 -> emf 2.4, eclipse 3.5 -> emf 2.5, eclipse 3.6 -> emf 2.6. <br />
:: The list of required plugins is:<br />
::: org.eclipse.emf.common<br />
::: org.eclipse.emf.ecore<br />
::: org.eclipse.emf.edit<br />
::: org.eclipse.emf.common.ui<br />
::: org.eclipse.emf.edit.ui<br />
:: Clearly it is possible to install more plugins, like the whole emf runtime or sdk<br />
:* CDT<br />
:: The main page to download CDT is [http://www.eclipse.org/cdt/downloads.php CDT Downloads].<br />
:: Also here, the version to download is related to eclipse version. <br />
:: In this case is required only the cdt runtime plugin.<br />
: [http://erika.tuxfamily.org/forum/viewtopic.php?f=6&t=651&sid=89784e2d97765c3f1c41f6e3c049437a#p727 Forum Post (in italian) about installing the Eclipse plugins]<br />
* Step 1:<br />
: Open ''Eclipse'';<br />
: From the menu ''Help'' select ''Install New Software...'';<br />
: Add with the button ''Add...'' the reference site mentioned above (fill the Location field with this: http://download.tuxfamily.org/erika/webdownload/rtdruid_beta);<br />
: Tick all plug-ins related to RT-Druid core and to Erika Enterprise, then click on the button ''Next'' to install them;<br />
: Restart Eclipse;<br />
* Step 2:<br />
: From the menu ''File'' select ''New'' and then RT-Druid Oil and C/C++ Project;<br />
: From the Project menu select one of the available e200 demo tests;<br />
: Then click on the project name with the right mouse button and build to obtain the elf object module for debugging;<br />
<br />
=== Additional software ===<br />
<br />
ERIKA uses GNU make and some command-line utilities to build programs. You need the following tools (please notice that only the less common commands are listed here; very common commands that are present in any Unix/POSIX system like ''ls'' are not listed for simplicity):<br />
* make (GNU version)<br />
* gawk (GNU AWK)<br />
* sed<br />
* grep<br />
<br />
For Linux the above commands are present in virtually every standard installation; but you can always install them from the respective packages of your distributions.<br />
<br />
For Windows, [http://www.cygwin.com/ Cygwin] is recommended. Please make sure to include the above packages (package names are the same as the tool names).<br />
<br />
== HOWTOs ==<br />
* [[How to create, compile and debug an application for Freescale MPC5674F]]<br />
* [[How to run the MODISTARC regression tests for Freescale MPC5674F]]<br />
<br />
<br />
[[Category:Supported Devices]]</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Freescale_PPC_e200_(MPC_56xx)Freescale PPC e200 (MPC 56xx)2014-07-17T09:51:05Z<p>Francesco: /* Use of non volatile registers in Erika PowerPC */</p>
<hr />
<div>= Freescale PPC e200 (MPC 56xx) support =<br />
ERIKA Enterprise supports the PPC e200 family microcontrollers.<br />
The support for RT-Druid is available starting from release 1.5.0.<br />
The support includes: <br />
# Support MPC5674F (e200z7). MPC5668G (e200z6) is supported in version 1.6.0; version 1.6.1 will support both cores (z6 and z0) of the MPC5668G (already available on the [[ERIKA Enterprise and RT-Druid SVN Access|Subversion repository]]). Support for MPC5643L (e200z4).<br />
# Support for the WindRiver DIAB and Freescale CodeWarrior compilers.<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers<br />
** WindRiver DIAB C Compiler 5.5.1 and 5.8.0.<br />
** Freescale CodeWarrior:<br />
*** Windows: CodeWarrior Development Studio for MPC55xx/56xx 2.7<br />
*** Linux: CodeWarrior Development Studio for MCU 10.2<br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: Currently limited to the MPC5668G and MPC5643L, it follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ Autosar]: two instances of the operating systems run on the two cores, and communication between cores is performed with a few APIs and shared memory.<br />
<br />
* MMU Handling<br />
** Static global mappings to let all the application see all the memory/peripherals in the system; no memory protection is implemented and all the code is executed in supervisor mode.<br />
<br />
== Host Configuration ==<br />
<br />
* RT-Druid requires Java 1.6.<br />
* It is possible to use a version of ERIKA more recent than the one provided with RT-Druid; just download the ERIKA tree from the repository (see [[ERIKA Enterprise and RT-Druid SVN Access]]) and point the '''ERIKA_FILES''' environment variable to its location; see [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]] for some caveats.<br />
<br />
=== Wind River Diab ===<br />
* Compiler: The compiler commands (dcc, das, dld, and dar) are assumed to be reachable from the $PATH. If a specific version of them has to be used it must be specified in pkg/cfg/arch/cc_z7diab.mk<br />
* Operating system: The PPC e200 port has been developed under Debian testing/unstable as of May 2010; the only known requirement is Java 1.6 to run RT-Druid.<br />
* In the reference environment, the Diab toolchain was located in /opt/case/diabdata/<version> and Eclipse in /opt/eclipse. No hard requirement is made by the build system, as specified above. <br />
<br />
=== Freescale CodeWarrior ===<br />
*Compiler: The compiler directory can be specified using the environment variable '''PPC_CW_BASEDIR'''; this directory must contain the directories ''PA_Support'', and ''PA_Tools'' or ''PowerPC_EABI_Tools''. ERIKA makefiles find all the files they need with relatives paths from there. Please notice that makefiles require that the variable '''PPC_CW_BASEDIR''' do not contain any space. An evaluation or a limited version of the compiler can be downloaded from the [http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_DOWNLOADS Freescale Web site].<br />
*Operating system: both Linux and Windows are supported. CodeWarrior support has been developed under Debian Linux and Windows XP, but other (and more recent) versions should work. On Windows, ''Special Edition: CodeWarrior for Microcontrollers 10.5'' is currently used, and on Linux ''CodeWarrior Development Studio for MCU'' version 10.2. On Windows the Cygwin environment is used for ERIKA makefiles, so the '''PPC_CW_BASEDIR''' variable must use forward slashes '/' and must not contain spaces; you can always convert the path with the ''cygpath'' command. For example, in this case the value to use is <code>/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7</code>:<br />
$ cygpath.exe `cygpath.exe -ms "/c/Program Files/Freescale/CW for MPC55xx and MPC56xx 2.7"`<br />
/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7<br />
*OIL file: Currently, an ''EEOPT'' with value '''"__CODEWARRIOR__"''' must be specified in the OIL file. See [[#OIL file configuration]] for more details.<br />
<br />
== Target configuration and programming==<br />
<br />
* ERIKA is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]<br />
* ERIKA supports the Freescale MPC5674F, MPC5668G and MPC5643L MCUs (we have been able to run it on an MPC56XX and others; Freescale MCUs are really very similar).<br />
* At system boot the interrupt controller is set up to work in Software Vector Mode, and all the interrupts are associated to default handlers. The kernel does not use any specific device/interrupts, although for testing purposes it is possible to use the decrementer and some gpios as interrupt sources. All the code is executed from flash, all the data sections are loaded into the SRAM at boot time (the MMU is configured to provide 1:1 mappings for code running in system mode for all the sensible regions, like flash, sram and device registers).<br />
* The version in the repository supports both FLE and VLE modes.<br />
* The scripts generated by the build process are compatible with Lauterbach v200912. The commands generated to setup the NEXUS port are not compatible with older releases of the Lauterbach software. In case you hit this problem, remove the NEXUS.* lines from the generated scripts, ad set up the port according to the Lauterbach version you are using.<br />
* Target registers are used according the PPC ABI described in the DIAB manual.<br />
* The stack fill pattern is configurable at compile time, but is assumed to be 0xa5.<br />
* For Osek conformance classes, which support TerminateTask(), each running task requires 96 bytes of stack. <br />
For multistack configurations, 76 bytes are required on each stack for context switching. You can add this numbers to the requirements of your application to estimate task usage.<br />
* Stack pointer is aligned at 16 byte (fixed in version 1.6)<br />
<br />
=== MCUs ===<br />
* The MCUs supported are currently the following:<br />
** MPC5674F (Mamba)<br />
** MPC5668G (Fado)<br />
** MPC5643L (Leopard)<br />
<br />
===OIL file configuration===<br />
For more information about configuration through OIL file, see [[Tutorial: RT-Druid and OIL basics]]. Here only the e200zX-specific part of OIL is described.<br />
;CPU (CPU_DATA)<br />
: CPU must be set to E200ZX. The exact model is specified with the '''MODEL''' item (supported values are '''E200Z0''', '''E200Z6''' , '''E200Z7''' and '''E200Z4'''. Generation of VLE code can be selected by setting '''VLE''' to '''TRUE'''; please notice that all the application and the OS code must have the same setting, as ERIKA makefiles do not support mixed programs. Size in byte of the shared stack can be specified with the optional '''SYS_STACK_SIZE''' item.<br />
: Example of a CPU_DATA section:<br />
CPU_DATA = PPCE200ZX {<br />
ID = "MainCpu";<br />
MODEL = E200Z7;<br />
APP_SRC = "main.c";<br />
MULTI_STACK = FALSE;<br />
VLE = FALSE;<br />
SYS_STACK_SIZE = 512;<br />
};<br />
:On multicore systems, one CPU_DATA instance can exist for each core. They must have different '''ID'''s. See [[ERIKA multicore support]] for more details about multicore systems on Erika.<br />
;MCU<br />
: MCU support is present for MPC5674F ,MPC5668G and MPC5643L. The only item supported is '''MODEL''', which can be either '''MPC5674F''', '''MPC5668G''' or '''MPC5643L'''. Most of the differences produced by this setting affect memory map and Lauterbach scripts.<br />
: Example:<br />
MCU_DATA = PPCE200ZX {<br />
MODEL = MPC5674F;<br />
};<br />
;System Timer<br />
Erika on PowerPC has a system timer based on PowerPC Decrementer. This feature is available for all supported MCUs: MPC5674F (Mamba), MPC5668G(Fado) and MPC5643L (Leopard). System time also requires CPU_CLOCK field to be set on CPU_DATA, hence CPU_CLOCK value must be added in CPU_DATA configuration to have a system timer configured.<br />
This is an example to configure Decrementer as System Timer:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_DECREMENTER";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "DECREMENTER";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
<br />
Furthermore for MPC5643L (Leopard) is available a system timer based on Freescale STM (System Timer Module), that is a device available in several Freescale PowerPC MCUs. In this case the following configuration must be take into account:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_STM";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
...<br />
...<br />
<br />
<br />
;EEOPTs<br />
: See also [[EEOPT]] for common EEOPTs.<br />
: Special options for the PPC e200 ERIKA porting can be specified through '''EE_OPT''' items in the '''OS''' section (please notice that the value for an '''EE_OPT''' is a string, so double quotes (") must be added around the values in this list.<br />
:; EE_SYSTEM_TIMER_DEVICE_DECREMENTER (see system timer section above)<br />
:; EE_SYSTEM_TIMER_DEVICE_STM (available only for MPC5643L, see system timer section above)<br />
:;EE_ISR_DYNAMIC_TABLE<br />
::Used to enable dynamic ISR table support that let register ISR handlers at runtime calling <code>EE_e200z7_register_ISR</code>.<br />
:;__E200ZX_EXECUTE_FROM_RAM__<br />
:: When specified, a linker script is used that maps both code and data in the RAM space. Executables produced with this option can be used only together with a debugger that loads the program in memory. By default, code and constant data are mapped to Flash, data to RAM.<br />
:;__CODEWARRIOR__<br />
:: Invoke Freescale CodeWarrior compiler. See [[#Freescale CodeWarrior]] for information on how to configure the compiler. The default compiler is Wind River Diab; see [[#Wind River Diab]] for configuration.<br />
:;__USE_CUSTOM_LINKER_SCRIPT__<br />
:: Don't use the dafault linker script. Users can direct the linker to use their own linker script by setting the <code>LDFLAGS</code> variable. Example:<br />
OS EE {<br />
EE_OPT = "__USE_CUSTOM_LINKER_SCRIPT__";<br />
LDFLAGS = "../my_linker_script.ld";<br />
};<br />
:;__USE_CUSTOM_CRT0__<br />
:: Don't use Erika default crt0. Users can provide their own crt0 by adding source files in the usual way (APP_SRC in the OIL file).<br />
;;__MINIMAL_CC_OPTIONS__<br />
:: Enable only the compiler flags absolutely needed to compile Erika, so users can easily add their preferences in CFLAGS.<br />
;;__EE_USE_MMU__<br />
:: Enable the MMU support. The MMU can be configured by calling <code>EE_e200zx_mmu_setup()</code>. See the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> for more details. An example configuration can be found in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt>.<br />
;;__EE_CRT0_INIT_MMU__<br />
:: Initialize the MMU from the crt0. See <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt> for an example, and the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt>.<br />
;;EE_NO_LIBEE<br />
:: To not generete the kernel library '''libee.a''' but link all the objects files (kernel + application) directly in an elf file. This option is useful to try Erika with CodeWarrior compiler with an evaluation license, because the archiver is not enabled with this license.<br />
;;DEBUG<br />
:: On this architecture, enabling debug symbols does not inhibit optimization.<br />
;;MPC5643L_STD_SW_MMU_CONFIG"<br />
:: This EE_OPT is valid only for MPC5643L (Leopard) and provides a standard (and in most cases sufficient) MMU configuration. This option is useful expecially running your code from FLASH where Debugger does not initializes the MMU for you.<br />
;;EE_LAUTERBACH_DEMO_SIM<br />
:: This option is available only for Mamba (MPC5674F), for details please take a look at DEMO_ErikaSim in the directory of templates. It causes the generation of Lauterbach scripts to use with Lauterbach simulator.<br />
<br />
There are a few examples in the ERIKA code base that can be used as a starting point for new projects. Examples include also a makefile, which can be used to compile a project without a need of an IDE. The makefile runs RT-Druid non-interactively, and requires the environment variable '''RTDRUID_ECLIPSE_HOME''' to point to the Eclipse directory where RT-Druid is installed.<br />
<br />
Examples can be accessed as templates in RT-Druid (see [[How to create, compile and debug an application for Freescale MPC5674F]]), or directly in the source code: [http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/ examples/ppc/].<br />
<br />
In the first version of ERIKA and RT-Druid supporting e200zX, the only e200-specific setting in the OIL configuration file was the CPU_DATA value, which had to be set to '''MPC5674F''' instead of '''PPCE200ZX'''. This not supported any more.<br />
<br />
=== APIs ===<br />
* List of functions (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_irq.h?view=markup pkg/cpu/e200zx/inc/ee_irq.h]</tt> for prototypes and other details):<br />
** EE_e200z7_register_ISR(level, handler, priority): Associate <tt>handler</tt> to the IRQ <tt>level</tt>, with the given <tt>priority</tt> (available only if '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' is set).<br />
** EE_e200z7_setup_decrementer(delay): Configure the decrementer to raise an interrupt every <tt>delay</tt> cycles.<br />
** EE_e200z7_setup_decrementer_oneshot(delay): Configure the decrementer to raise an interrupt <tt>delay</tt> cycles after invocation.<br />
** EE_e200z7_stop_decrementer(): Stop the decrementer from generating interrupts.<br />
** EE_e200zx_setup_fixed_intv(bitpos): Enable the fixed-interval interrupt.<br />
** EE_e200zx_stop_fixed_intv(): Disable the fixed-interval interrupt.<br />
** EE_e200zx_mmu_setup(entries, count): MMU initialization.<br />
<br />
Note: notice that the *_e200z7_* is slightly misleading since it seem to refer only to e200z7 family, it is a legacy name convention when the only supported architecture by Erika was Z7. Currently even Z0, Z4 and Z6 are supported hence these functions can be used for such architectures, although it refers to *_e200z7_*.<br />
<br />
====Interrupts====<br />
<br />
There are two way to configure ISR. The standard way is the static way with OIL configuration (example):<br />
<br />
ISR DecrIsr {<br />
CATEGORY = 2;<br />
ENTRY = "DECREMENTER";<br />
};<br />
<br />
ISR FixedIntvIsr {<br />
CATEGORY = 2;<br />
ENTRY = "FIXED_INTV";<br />
HANDLER = "fixed_intv_handler";<br />
};<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
ENTRY = "0";<br />
};<br />
ISR IsrMedium {<br />
CATEGORY = 2;<br />
PRIORITY = 2;<br />
ENTRY = "1";<br />
};<br />
<br />
ISR IsrHigh {<br />
CATEGORY = ;<br />
PRIORITY = 3;<br />
ENTRY = "2";<br />
HANDLER = "isr_high_handler";<br />
};<br />
<br />
In static ISR table handling mode there's full support for both ISR1 and ISR2 for '''external interrupt'''. To register an handler you should use the suitable macro ('''ISR1''' or '''ISR2''') passing the value of '''HANDLER''' field or the '''ISR name''', in case the former is missing. The configuration field '''ENTRY''' declare the position of the handler inside the vector table (the example show three handlers that get the first three positions in vector, corrisponding to the first three software interrupt request). Priority field corripsond to interrupt priority value set to corrisponding Interrupt Controller Priority select registers ('''INTC.PSR[(ENTRY)] = PRIORITY'''), the values have to be inside [0..15] range.<br />
<br />
There is direct support for two cpu '''internal exceptions''', those generated by the time base facilities: decrementer and fixed interval timer ('''ENTRY = "DECREMENTER"''' and '''ENTRY = "FIXED_INTV"'''' respectively.). Support for Watch-Dog timer will be added. To register an handler for internal interrupt you have to use '''ISR1_INT''' or '''ISR2_INT''' (two different couple of macros are needed to issue EOI, End Of Interrupt, only for external interrupts). Priority field in configuration have no meaning for internal interrupts.<br />
<br />
You can register handler by code dinamically with with the <code>EE_e200z7_register_ISR()</code> described above. To enable dynamic ISR table support you must declare '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' configuration OIL file. The '''first 16 level''' of dynamic table are reserved for '''internal exceptions''' handlers, so you have to add this offset to the '''ENTRY''' value of the static approach to register an handler to the same interrupt source.<br />
<br />
ISRs (Interrupt Service Routines) are just void functions with no arguments. For external interrupts (IVOR4), the EOI (End Of Interrupt) is issued by ERIKA's handler; user ISRs need not bother about that.<br />
<br />
====Multicore support (MPC5668 and MPC5643L)====<br />
* Functions used for multicore support on MPC5668 (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5668/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5668/inc/ee_dual.h]</tt> for prototypes and other details):<br />
** EE_mpc5668_start_z0(f): Enable the z0 CPU.<br />
<br />
The same paradigm of multicore support available for MPC5668G, is also available for the MPC5643L, (for details see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5643l/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5643l/inc/ee_dual.h]</tt>). Likewise MPC5668G, in order to start the slave core, a EE_mpc5643l_start_slave(f) call has to be provided at startup (typically in main function) immediately before the StartOS().<br />
<br />
=== Boards ===<br />
* ERIKA has been developed on an '''Axiom MPC5674evbfxmb evaluation board'''. This evaluation board has the MAMBA microcontroller (Freescale MPC5674F)<br />
** The kernel has no dependency on the board itself, but some of its functionalities can be used for debugging purposes. Including file "pkg/board/axiom_mpc5674fxmb/inc/ee_board.h" the following functions can be used:<br />
*** EE_leds_init(): which sets up the GPIOs associated with the leds.<br />
*** EE_EE_leds(mask): which turns the i-th led on or off depending on the state of the i-th bit in the mask passed as an argument.<br />
*** EE_led_<X>_on()/EE_led_<X>_off(): turns led X on or off.<br />
*** EE_buttons_disable_interrupts(button): disables the interrupt associated to the given button.<br />
*** EE_buttons_enable_interrupts(button): enables it.<br />
*** EE_buttons_clear_ISRflag(button): acknowledges the interrupt coming from the given button.<br />
*** EE_button_get_B<X>(): gets the status of button X.<br />
*** EE_buttons_init(): initializes the GPIOs associated to buttons.<br />
** The functions above are available if, respectively, __USE_LEDS__ and __USE_BUTTONS__ are defined upon inclusion of ee_board.h<br />
** The connections are assumed to be the following:<br />
*** GPIO 147-150: connected to LED0-3. Looking at the pins on the EVB:<br />
**** ETPUB1 -> USER_LED1<br />
**** ETPUB2 -> USER_LED2<br />
**** ETPUB3 -> USER_LED3<br />
*** GPIO 450: connected to BUTTON0 (ETPUC9 -> USER_DEV1)<br />
<br />
* Erika is available for the '''Freescale MPC5668EVB Evaluation Board'''. This evaluation board has the FADO microcontroller (Freescale MPC5668G)<br />
** for this board the are no available support for leds or buttons.<br />
<br />
* Erika is available for '''Freescale MPC564xLEVB Evaluation Board'''. This evaluation board has the LEOPARD microcontroller (Freescale MPC5643L)<br />
** for this board there is the same set of primitives defined for "Axiom MPC5674evbfxmb" board, hence a basic support for leds and button is available.<br />
<br />
== Multicore support ==<br />
<br />
In the ERIKA multicore support for PPC e200 there are a few aspects specific to the PPC e200 architecture, and they are described here. Please refer to [[ERIKA multicore support]] for general information on ERIKA multicore systems.<br />
<br />
The PPC evaluation board supported by Erika Multicore is the Freescale MPC5668G/E Evaluation kit, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5668GKIT. The multicore support is also provided for MPC5643L with the Freescale evaluation board MPC564xL EVB, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=XKT564L.<br />
<br />
In multicore configuration, is it possible running both instances of the operating system both in RAM and Flash. For instance on MPC5668G, the internal SRAM is partitioned statically in two: memory from 0x40000000 to 0x4001FFFF is reserved to the first core and shared variables, while memory from 0x40020000 to 0x4003FFFF is reserved to the second core. 0x40020000 is used as the starting address of the second core. A similar approach is available for MPC5643L. In order to customize such memory assignments please refer to memory0.ld and memory1.ld files in "erika/pkg/mcu/freescale_mpc56XX/cfg/multicore" (where XX=43l for Leopard and XX=68 for Fado).<br />
<br />
Shared variable data is allocated in a single section (<tt>.mcglobald</tt>). Access to this section must be performed without cache, or the OS may malfunction. ERIKA crt0 does not enable cache; if you want to enable it, you should also make sure that the <tt>.mcglobald</tt> section is allocated on a page on its own by the linker script, and that the MMU is configured to mark such page as non-cached. <br />
<br />
The OS uses two software interrupts (6 and 7) and two hardware semaphores (0 and 1) of the MPC5668G to handle inter-core communication. They are initialised inside <code>StartOS()</code>. While all the other software interrupts and semaphores are available for user applications, those used by the OS should not be meddled with by user code. It is okay to briefly mask the interrupts with higher-priority interrupts or by disabling interrupts. In case of MPC5643L, as the microcontroller has two different interrupt controllers (one for each core), SW interrupt number 7 is used for both cores. Even if the MPC5643L has two SEMA4 modules, only the first module (the one associated to the master core) is used for this mechanism, this means that semaphores 0 and 1 of the first SEMA4 module are used for synchronisation (as in MPC5668G), while the remaining semaphores of the first SEMA4 module and all semaphores belonging to the second SEMA4 module are available for user applications.<br />
<br />
Examples of multicore applications are in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/ examples/ppc/dual_examples]</tt>. In particular, <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/mono_activate01/ examples/ppc/dual_examples/mono_activate01]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/multi_event01/ examples/ppc/dual_examples/multi_event01]</tt> are complete applications, nearer to real-world usage.<br />
<br />
Erika multicore for PowerPC supports AUTOSAR OS-like functionalities. For details please see the following page (but take into account that these features have not been published yet):<br />
[[Erika AUTOSAR OS]]<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for PPC e200 produces a Lauterbach Trace32 configuration file (<tt>t32.cmm</tt>) and a ORTI description file (<tt>system.orti</tt>) inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger, please issue <code>t32mppc</code> from the output directory. The ERIKA build system honors the <tt>T32SYS</tt> environment variable, if set.<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named <tt>start.sh</tt>) is produced in the output directory. To run the debugger, please issue <code>start.sh</code> from the output directory. The script creates two instances of the debugger, one for each core. For instace when MPC5668G is turned on, only the first (Z6) core is enabled. In order to simulate the real setup, the debugger connected to the second (Z0) core does not enable its core, but it is responsibility of the code running on the Z6 core to enable the Z0 core (this is different from the example script for MPC5668G distributed with the Lauterbach Trace32 software). Nonetheless, the startup script loads all the code and the debug symbols for both core and both debugger instances. In a typical debugging session, you start the execution of the code on the Z6 core from its debugger, and then, when the Z0 core has become active, start also the code on the Z0 core from the Z0 debugger. The barrier inside <code>StartOS()</code> comes handy to synchronize the code running on the two cores. The <tt>start.sh</tt> script runs only on Linux; currently the ERIKA build system does not support Windows to run Trace32 for e200 multicore systems. A similar approach has been adopted for MPC5643L.<br />
<br />
==Internals==<br />
<br />
===Interrupts===<br />
<br />
Interrupt handling in PPC e200 ERIKA uses software vector mode and a single entry point for all interrupts and exceptions, which is <code>EE_e200z7_irq()</code>. This function calls the user ISR and issues the end-of-interrupt for external interrupts; when the served interrupt is not nested, i.e., it interrupted a task directly, <code>EE_e200z7_irq()</code> also calls the scheduler before returning.<br />
<br />
This scheme of IRQ handling can be changed by rewriting the crt0 and changing the IVOR setup. In this way it is possible, for example, to use hardware vector mode. Please note that it is important that the end-of-interrupt be issued before calling the scheduler, as the scheduler may not return when a new task is to be scheduled.<br />
<br />
===Use of non volatile registers in Erika PowerPC===<br />
<br />
Some Erika RTOS assembly modules in PowerPC use non volatile registers for their internal purposes (r14-r31). Such modules are:<br />
<br />
* ee_e200zx_contex.S - This module is in charge of managing context switch for multistack on e200zx<br />
* ee_oo.S - This module is in charge of saving and restoring registers for Osek TerminateTask() on e200zx<br />
* ee_entry.S - This module handles exception entry points and hardware setup for the e200zx<br />
* ee_boot.S - This module represents boot sequence for PowerPC MCUs.<br />
<br />
The use of r14-r31 registers is limited, just few lines of code. But this information is relevant in case advanced features of some compilers are used, (e.g.: to define additional non-standard SDAs, Small Data Area). For instance Windriver Diab compiler has the REGISTER directive in the linker script to fullfill this requirement. If this non-standard approach is not required this information can be neglected. It is provided in order to give the position of such code whenever the use of non volatile registers (r14-r31) is necessary for non-standard purposes. For details please refere to your compiler documentation.<br />
<br />
Assumption for future development: additional SDA base addresses will be stored starting from register r14<br />
<br />
== Download and install of Eclipse, RT-Druid, and ERIKA source ==<br />
<br />
To build an ERIKA application you need:<br />
* ERIKA source code<br />
* RT-Druid and a hosting Eclipse<br />
* Some command-line tools<br />
<br />
=== ERIKA source code ===<br />
<br />
ERIKA source code is bundled with RT-Druid. ERIKA for PPC e200 honors the definition of '''ERIKA_FILES''', so you can use the latest version of ERIKA as explained in [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]].<br />
<br />
=== Eclipse and RT-Druid in one piece ===<br />
<br />
A complete version of an Eclipse installation together with the RT-Druid plugin can be downloaded from this page:<br />
http://erika.tuxfamily.org/erika-for-multiple-devices.html. Please make sure to use a version not older than 1.6.0 beta. See also [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application]].<br />
<br />
=== Eclipse and RT-Druid piece by piece ===<br />
<br />
Alternatively, if you already have a copy of Eclipse or you want to use a version of Eclipse different from the one provided by the page above, you can follow this procedure.<br />
* To download the e200 plug-in for Eclipse refer the following site: [http://download.tuxfamily.org/erika/webdownload/rtdruid_beta Plug-in download site].<br />
Procedure for installation:<br />
* Step 0:<br />
: Get ''Eclipse'' and required plug-ins;<br />
: Where possible, the suggestion is to download the ''all in one update site'' and use the eclipse update manager or to use the eclipse update manager directly on a web site;<br />
:* Eclipse<br />
:: If you don't have any eclipse installations, you can download eclipse with cdt already installed from [http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/heliossr1 Eclipse IDE for C/C++].<br />
:: It is also possible use an already installed distribution of eclipse or to download one (for example from [http://www.eclipse.org/downloads Eclipse Downloads]) and then add all missing plug-ins.<br />
:* EMF<br />
:: The main page to download EMF is [http://www.eclipse.org/modeling/emf/downloads/?project=emf Eclipse Modeling Framework].<br />
:: The version to download is related to the eclipse version: eclipse 3.3 -> emf 2.3 , eclipse 3.4 -> emf 2.4, eclipse 3.5 -> emf 2.5, eclipse 3.6 -> emf 2.6. <br />
:: The list of required plugins is:<br />
::: org.eclipse.emf.common<br />
::: org.eclipse.emf.ecore<br />
::: org.eclipse.emf.edit<br />
::: org.eclipse.emf.common.ui<br />
::: org.eclipse.emf.edit.ui<br />
:: Clearly it is possible to install more plugins, like the whole emf runtime or sdk<br />
:* CDT<br />
:: The main page to download CDT is [http://www.eclipse.org/cdt/downloads.php CDT Downloads].<br />
:: Also here, the version to download is related to eclipse version. <br />
:: In this case is required only the cdt runtime plugin.<br />
: [http://erika.tuxfamily.org/forum/viewtopic.php?f=6&t=651&sid=89784e2d97765c3f1c41f6e3c049437a#p727 Forum Post (in italian) about installing the Eclipse plugins]<br />
* Step 1:<br />
: Open ''Eclipse'';<br />
: From the menu ''Help'' select ''Install New Software...'';<br />
: Add with the button ''Add...'' the reference site mentioned above (fill the Location field with this: http://download.tuxfamily.org/erika/webdownload/rtdruid_beta);<br />
: Tick all plug-ins related to RT-Druid core and to Erika Enterprise, then click on the button ''Next'' to install them;<br />
: Restart Eclipse;<br />
* Step 2:<br />
: From the menu ''File'' select ''New'' and then RT-Druid Oil and C/C++ Project;<br />
: From the Project menu select one of the available e200 demo tests;<br />
: Then click on the project name with the right mouse button and build to obtain the elf object module for debugging;<br />
<br />
=== Additional software ===<br />
<br />
ERIKA uses GNU make and some command-line utilities to build programs. You need the following tools (please notice that only the less common commands are listed here; very common commands that are present in any Unix/POSIX system like ''ls'' are not listed for simplicity):<br />
* make (GNU version)<br />
* gawk (GNU AWK)<br />
* sed<br />
* grep<br />
<br />
For Linux the above commands are present in virtually every standard installation; but you can always install them from the respective packages of your distributions.<br />
<br />
For Windows, [http://www.cygwin.com/ Cygwin] is recommended. Please make sure to include the above packages (package names are the same as the tool names).<br />
<br />
== HOWTOs ==<br />
* [[How to create, compile and debug an application for Freescale MPC5674F]]<br />
* [[How to run the MODISTARC regression tests for Freescale MPC5674F]]<br />
<br />
<br />
[[Category:Supported Devices]]</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Freescale_PPC_e200_(MPC_56xx)Freescale PPC e200 (MPC 56xx)2014-07-17T08:04:42Z<p>Francesco: /* Internals */</p>
<hr />
<div>= Freescale PPC e200 (MPC 56xx) support =<br />
ERIKA Enterprise supports the PPC e200 family microcontrollers.<br />
The support for RT-Druid is available starting from release 1.5.0.<br />
The support includes: <br />
# Support MPC5674F (e200z7). MPC5668G (e200z6) is supported in version 1.6.0; version 1.6.1 will support both cores (z6 and z0) of the MPC5668G (already available on the [[ERIKA Enterprise and RT-Druid SVN Access|Subversion repository]]). Support for MPC5643L (e200z4).<br />
# Support for the WindRiver DIAB and Freescale CodeWarrior compilers.<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers<br />
** WindRiver DIAB C Compiler 5.5.1 and 5.8.0.<br />
** Freescale CodeWarrior:<br />
*** Windows: CodeWarrior Development Studio for MPC55xx/56xx 2.7<br />
*** Linux: CodeWarrior Development Studio for MCU 10.2<br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: Currently limited to the MPC5668G and MPC5643L, it follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ Autosar]: two instances of the operating systems run on the two cores, and communication between cores is performed with a few APIs and shared memory.<br />
<br />
* MMU Handling<br />
** Static global mappings to let all the application see all the memory/peripherals in the system; no memory protection is implemented and all the code is executed in supervisor mode.<br />
<br />
== Host Configuration ==<br />
<br />
* RT-Druid requires Java 1.6.<br />
* It is possible to use a version of ERIKA more recent than the one provided with RT-Druid; just download the ERIKA tree from the repository (see [[ERIKA Enterprise and RT-Druid SVN Access]]) and point the '''ERIKA_FILES''' environment variable to its location; see [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]] for some caveats.<br />
<br />
=== Wind River Diab ===<br />
* Compiler: The compiler commands (dcc, das, dld, and dar) are assumed to be reachable from the $PATH. If a specific version of them has to be used it must be specified in pkg/cfg/arch/cc_z7diab.mk<br />
* Operating system: The PPC e200 port has been developed under Debian testing/unstable as of May 2010; the only known requirement is Java 1.6 to run RT-Druid.<br />
* In the reference environment, the Diab toolchain was located in /opt/case/diabdata/<version> and Eclipse in /opt/eclipse. No hard requirement is made by the build system, as specified above. <br />
<br />
=== Freescale CodeWarrior ===<br />
*Compiler: The compiler directory can be specified using the environment variable '''PPC_CW_BASEDIR'''; this directory must contain the directories ''PA_Support'', and ''PA_Tools'' or ''PowerPC_EABI_Tools''. ERIKA makefiles find all the files they need with relatives paths from there. Please notice that makefiles require that the variable '''PPC_CW_BASEDIR''' do not contain any space. An evaluation or a limited version of the compiler can be downloaded from the [http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_DOWNLOADS Freescale Web site].<br />
*Operating system: both Linux and Windows are supported. CodeWarrior support has been developed under Debian Linux and Windows XP, but other (and more recent) versions should work. On Windows, ''Special Edition: CodeWarrior for Microcontrollers 10.5'' is currently used, and on Linux ''CodeWarrior Development Studio for MCU'' version 10.2. On Windows the Cygwin environment is used for ERIKA makefiles, so the '''PPC_CW_BASEDIR''' variable must use forward slashes '/' and must not contain spaces; you can always convert the path with the ''cygpath'' command. For example, in this case the value to use is <code>/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7</code>:<br />
$ cygpath.exe `cygpath.exe -ms "/c/Program Files/Freescale/CW for MPC55xx and MPC56xx 2.7"`<br />
/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7<br />
*OIL file: Currently, an ''EEOPT'' with value '''"__CODEWARRIOR__"''' must be specified in the OIL file. See [[#OIL file configuration]] for more details.<br />
<br />
== Target configuration and programming==<br />
<br />
* ERIKA is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]<br />
* ERIKA supports the Freescale MPC5674F, MPC5668G and MPC5643L MCUs (we have been able to run it on an MPC56XX and others; Freescale MCUs are really very similar).<br />
* At system boot the interrupt controller is set up to work in Software Vector Mode, and all the interrupts are associated to default handlers. The kernel does not use any specific device/interrupts, although for testing purposes it is possible to use the decrementer and some gpios as interrupt sources. All the code is executed from flash, all the data sections are loaded into the SRAM at boot time (the MMU is configured to provide 1:1 mappings for code running in system mode for all the sensible regions, like flash, sram and device registers).<br />
* The version in the repository supports both FLE and VLE modes.<br />
* The scripts generated by the build process are compatible with Lauterbach v200912. The commands generated to setup the NEXUS port are not compatible with older releases of the Lauterbach software. In case you hit this problem, remove the NEXUS.* lines from the generated scripts, ad set up the port according to the Lauterbach version you are using.<br />
* Target registers are used according the PPC ABI described in the DIAB manual.<br />
* The stack fill pattern is configurable at compile time, but is assumed to be 0xa5.<br />
* For Osek conformance classes, which support TerminateTask(), each running task requires 96 bytes of stack. <br />
For multistack configurations, 76 bytes are required on each stack for context switching. You can add this numbers to the requirements of your application to estimate task usage.<br />
* Stack pointer is aligned at 16 byte (fixed in version 1.6)<br />
<br />
=== MCUs ===<br />
* The MCUs supported are currently the following:<br />
** MPC5674F (Mamba)<br />
** MPC5668G (Fado)<br />
** MPC5643L (Leopard)<br />
<br />
===OIL file configuration===<br />
For more information about configuration through OIL file, see [[Tutorial: RT-Druid and OIL basics]]. Here only the e200zX-specific part of OIL is described.<br />
;CPU (CPU_DATA)<br />
: CPU must be set to E200ZX. The exact model is specified with the '''MODEL''' item (supported values are '''E200Z0''', '''E200Z6''' , '''E200Z7''' and '''E200Z4'''. Generation of VLE code can be selected by setting '''VLE''' to '''TRUE'''; please notice that all the application and the OS code must have the same setting, as ERIKA makefiles do not support mixed programs. Size in byte of the shared stack can be specified with the optional '''SYS_STACK_SIZE''' item.<br />
: Example of a CPU_DATA section:<br />
CPU_DATA = PPCE200ZX {<br />
ID = "MainCpu";<br />
MODEL = E200Z7;<br />
APP_SRC = "main.c";<br />
MULTI_STACK = FALSE;<br />
VLE = FALSE;<br />
SYS_STACK_SIZE = 512;<br />
};<br />
:On multicore systems, one CPU_DATA instance can exist for each core. They must have different '''ID'''s. See [[ERIKA multicore support]] for more details about multicore systems on Erika.<br />
;MCU<br />
: MCU support is present for MPC5674F ,MPC5668G and MPC5643L. The only item supported is '''MODEL''', which can be either '''MPC5674F''', '''MPC5668G''' or '''MPC5643L'''. Most of the differences produced by this setting affect memory map and Lauterbach scripts.<br />
: Example:<br />
MCU_DATA = PPCE200ZX {<br />
MODEL = MPC5674F;<br />
};<br />
;System Timer<br />
Erika on PowerPC has a system timer based on PowerPC Decrementer. This feature is available for all supported MCUs: MPC5674F (Mamba), MPC5668G(Fado) and MPC5643L (Leopard). System time also requires CPU_CLOCK field to be set on CPU_DATA, hence CPU_CLOCK value must be added in CPU_DATA configuration to have a system timer configured.<br />
This is an example to configure Decrementer as System Timer:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_DECREMENTER";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "DECREMENTER";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
<br />
Furthermore for MPC5643L (Leopard) is available a system timer based on Freescale STM (System Timer Module), that is a device available in several Freescale PowerPC MCUs. In this case the following configuration must be take into account:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_STM";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
...<br />
...<br />
<br />
<br />
;EEOPTs<br />
: See also [[EEOPT]] for common EEOPTs.<br />
: Special options for the PPC e200 ERIKA porting can be specified through '''EE_OPT''' items in the '''OS''' section (please notice that the value for an '''EE_OPT''' is a string, so double quotes (") must be added around the values in this list.<br />
:; EE_SYSTEM_TIMER_DEVICE_DECREMENTER (see system timer section above)<br />
:; EE_SYSTEM_TIMER_DEVICE_STM (available only for MPC5643L, see system timer section above)<br />
:;EE_ISR_DYNAMIC_TABLE<br />
::Used to enable dynamic ISR table support that let register ISR handlers at runtime calling <code>EE_e200z7_register_ISR</code>.<br />
:;__E200ZX_EXECUTE_FROM_RAM__<br />
:: When specified, a linker script is used that maps both code and data in the RAM space. Executables produced with this option can be used only together with a debugger that loads the program in memory. By default, code and constant data are mapped to Flash, data to RAM.<br />
:;__CODEWARRIOR__<br />
:: Invoke Freescale CodeWarrior compiler. See [[#Freescale CodeWarrior]] for information on how to configure the compiler. The default compiler is Wind River Diab; see [[#Wind River Diab]] for configuration.<br />
:;__USE_CUSTOM_LINKER_SCRIPT__<br />
:: Don't use the dafault linker script. Users can direct the linker to use their own linker script by setting the <code>LDFLAGS</code> variable. Example:<br />
OS EE {<br />
EE_OPT = "__USE_CUSTOM_LINKER_SCRIPT__";<br />
LDFLAGS = "../my_linker_script.ld";<br />
};<br />
:;__USE_CUSTOM_CRT0__<br />
:: Don't use Erika default crt0. Users can provide their own crt0 by adding source files in the usual way (APP_SRC in the OIL file).<br />
;;__MINIMAL_CC_OPTIONS__<br />
:: Enable only the compiler flags absolutely needed to compile Erika, so users can easily add their preferences in CFLAGS.<br />
;;__EE_USE_MMU__<br />
:: Enable the MMU support. The MMU can be configured by calling <code>EE_e200zx_mmu_setup()</code>. See the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> for more details. An example configuration can be found in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt>.<br />
;;__EE_CRT0_INIT_MMU__<br />
:: Initialize the MMU from the crt0. See <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt> for an example, and the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt>.<br />
;;EE_NO_LIBEE<br />
:: To not generete the kernel library '''libee.a''' but link all the objects files (kernel + application) directly in an elf file. This option is useful to try Erika with CodeWarrior compiler with an evaluation license, because the archiver is not enabled with this license.<br />
;;DEBUG<br />
:: On this architecture, enabling debug symbols does not inhibit optimization.<br />
;;MPC5643L_STD_SW_MMU_CONFIG"<br />
:: This EE_OPT is valid only for MPC5643L (Leopard) and provides a standard (and in most cases sufficient) MMU configuration. This option is useful expecially running your code from FLASH where Debugger does not initializes the MMU for you.<br />
;;EE_LAUTERBACH_DEMO_SIM<br />
:: This option is available only for Mamba (MPC5674F), for details please take a look at DEMO_ErikaSim in the directory of templates. It causes the generation of Lauterbach scripts to use with Lauterbach simulator.<br />
<br />
There are a few examples in the ERIKA code base that can be used as a starting point for new projects. Examples include also a makefile, which can be used to compile a project without a need of an IDE. The makefile runs RT-Druid non-interactively, and requires the environment variable '''RTDRUID_ECLIPSE_HOME''' to point to the Eclipse directory where RT-Druid is installed.<br />
<br />
Examples can be accessed as templates in RT-Druid (see [[How to create, compile and debug an application for Freescale MPC5674F]]), or directly in the source code: [http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/ examples/ppc/].<br />
<br />
In the first version of ERIKA and RT-Druid supporting e200zX, the only e200-specific setting in the OIL configuration file was the CPU_DATA value, which had to be set to '''MPC5674F''' instead of '''PPCE200ZX'''. This not supported any more.<br />
<br />
=== APIs ===<br />
* List of functions (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_irq.h?view=markup pkg/cpu/e200zx/inc/ee_irq.h]</tt> for prototypes and other details):<br />
** EE_e200z7_register_ISR(level, handler, priority): Associate <tt>handler</tt> to the IRQ <tt>level</tt>, with the given <tt>priority</tt> (available only if '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' is set).<br />
** EE_e200z7_setup_decrementer(delay): Configure the decrementer to raise an interrupt every <tt>delay</tt> cycles.<br />
** EE_e200z7_setup_decrementer_oneshot(delay): Configure the decrementer to raise an interrupt <tt>delay</tt> cycles after invocation.<br />
** EE_e200z7_stop_decrementer(): Stop the decrementer from generating interrupts.<br />
** EE_e200zx_setup_fixed_intv(bitpos): Enable the fixed-interval interrupt.<br />
** EE_e200zx_stop_fixed_intv(): Disable the fixed-interval interrupt.<br />
** EE_e200zx_mmu_setup(entries, count): MMU initialization.<br />
<br />
Note: notice that the *_e200z7_* is slightly misleading since it seem to refer only to e200z7 family, it is a legacy name convention when the only supported architecture by Erika was Z7. Currently even Z0, Z4 and Z6 are supported hence these functions can be used for such architectures, although it refers to *_e200z7_*.<br />
<br />
====Interrupts====<br />
<br />
There are two way to configure ISR. The standard way is the static way with OIL configuration (example):<br />
<br />
ISR DecrIsr {<br />
CATEGORY = 2;<br />
ENTRY = "DECREMENTER";<br />
};<br />
<br />
ISR FixedIntvIsr {<br />
CATEGORY = 2;<br />
ENTRY = "FIXED_INTV";<br />
HANDLER = "fixed_intv_handler";<br />
};<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
ENTRY = "0";<br />
};<br />
ISR IsrMedium {<br />
CATEGORY = 2;<br />
PRIORITY = 2;<br />
ENTRY = "1";<br />
};<br />
<br />
ISR IsrHigh {<br />
CATEGORY = ;<br />
PRIORITY = 3;<br />
ENTRY = "2";<br />
HANDLER = "isr_high_handler";<br />
};<br />
<br />
In static ISR table handling mode there's full support for both ISR1 and ISR2 for '''external interrupt'''. To register an handler you should use the suitable macro ('''ISR1''' or '''ISR2''') passing the value of '''HANDLER''' field or the '''ISR name''', in case the former is missing. The configuration field '''ENTRY''' declare the position of the handler inside the vector table (the example show three handlers that get the first three positions in vector, corrisponding to the first three software interrupt request). Priority field corripsond to interrupt priority value set to corrisponding Interrupt Controller Priority select registers ('''INTC.PSR[(ENTRY)] = PRIORITY'''), the values have to be inside [0..15] range.<br />
<br />
There is direct support for two cpu '''internal exceptions''', those generated by the time base facilities: decrementer and fixed interval timer ('''ENTRY = "DECREMENTER"''' and '''ENTRY = "FIXED_INTV"'''' respectively.). Support for Watch-Dog timer will be added. To register an handler for internal interrupt you have to use '''ISR1_INT''' or '''ISR2_INT''' (two different couple of macros are needed to issue EOI, End Of Interrupt, only for external interrupts). Priority field in configuration have no meaning for internal interrupts.<br />
<br />
You can register handler by code dinamically with with the <code>EE_e200z7_register_ISR()</code> described above. To enable dynamic ISR table support you must declare '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' configuration OIL file. The '''first 16 level''' of dynamic table are reserved for '''internal exceptions''' handlers, so you have to add this offset to the '''ENTRY''' value of the static approach to register an handler to the same interrupt source.<br />
<br />
ISRs (Interrupt Service Routines) are just void functions with no arguments. For external interrupts (IVOR4), the EOI (End Of Interrupt) is issued by ERIKA's handler; user ISRs need not bother about that.<br />
<br />
====Multicore support (MPC5668 and MPC5643L)====<br />
* Functions used for multicore support on MPC5668 (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5668/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5668/inc/ee_dual.h]</tt> for prototypes and other details):<br />
** EE_mpc5668_start_z0(f): Enable the z0 CPU.<br />
<br />
The same paradigm of multicore support available for MPC5668G, is also available for the MPC5643L, (for details see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5643l/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5643l/inc/ee_dual.h]</tt>). Likewise MPC5668G, in order to start the slave core, a EE_mpc5643l_start_slave(f) call has to be provided at startup (typically in main function) immediately before the StartOS().<br />
<br />
=== Boards ===<br />
* ERIKA has been developed on an '''Axiom MPC5674evbfxmb evaluation board'''. This evaluation board has the MAMBA microcontroller (Freescale MPC5674F)<br />
** The kernel has no dependency on the board itself, but some of its functionalities can be used for debugging purposes. Including file "pkg/board/axiom_mpc5674fxmb/inc/ee_board.h" the following functions can be used:<br />
*** EE_leds_init(): which sets up the GPIOs associated with the leds.<br />
*** EE_EE_leds(mask): which turns the i-th led on or off depending on the state of the i-th bit in the mask passed as an argument.<br />
*** EE_led_<X>_on()/EE_led_<X>_off(): turns led X on or off.<br />
*** EE_buttons_disable_interrupts(button): disables the interrupt associated to the given button.<br />
*** EE_buttons_enable_interrupts(button): enables it.<br />
*** EE_buttons_clear_ISRflag(button): acknowledges the interrupt coming from the given button.<br />
*** EE_button_get_B<X>(): gets the status of button X.<br />
*** EE_buttons_init(): initializes the GPIOs associated to buttons.<br />
** The functions above are available if, respectively, __USE_LEDS__ and __USE_BUTTONS__ are defined upon inclusion of ee_board.h<br />
** The connections are assumed to be the following:<br />
*** GPIO 147-150: connected to LED0-3. Looking at the pins on the EVB:<br />
**** ETPUB1 -> USER_LED1<br />
**** ETPUB2 -> USER_LED2<br />
**** ETPUB3 -> USER_LED3<br />
*** GPIO 450: connected to BUTTON0 (ETPUC9 -> USER_DEV1)<br />
<br />
* Erika is available for the '''Freescale MPC5668EVB Evaluation Board'''. This evaluation board has the FADO microcontroller (Freescale MPC5668G)<br />
** for this board the are no available support for leds or buttons.<br />
<br />
* Erika is available for '''Freescale MPC564xLEVB Evaluation Board'''. This evaluation board has the LEOPARD microcontroller (Freescale MPC5643L)<br />
** for this board there is the same set of primitives defined for "Axiom MPC5674evbfxmb" board, hence a basic support for leds and button is available.<br />
<br />
== Multicore support ==<br />
<br />
In the ERIKA multicore support for PPC e200 there are a few aspects specific to the PPC e200 architecture, and they are described here. Please refer to [[ERIKA multicore support]] for general information on ERIKA multicore systems.<br />
<br />
The PPC evaluation board supported by Erika Multicore is the Freescale MPC5668G/E Evaluation kit, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5668GKIT. The multicore support is also provided for MPC5643L with the Freescale evaluation board MPC564xL EVB, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=XKT564L.<br />
<br />
In multicore configuration, is it possible running both instances of the operating system both in RAM and Flash. For instance on MPC5668G, the internal SRAM is partitioned statically in two: memory from 0x40000000 to 0x4001FFFF is reserved to the first core and shared variables, while memory from 0x40020000 to 0x4003FFFF is reserved to the second core. 0x40020000 is used as the starting address of the second core. A similar approach is available for MPC5643L. In order to customize such memory assignments please refer to memory0.ld and memory1.ld files in "erika/pkg/mcu/freescale_mpc56XX/cfg/multicore" (where XX=43l for Leopard and XX=68 for Fado).<br />
<br />
Shared variable data is allocated in a single section (<tt>.mcglobald</tt>). Access to this section must be performed without cache, or the OS may malfunction. ERIKA crt0 does not enable cache; if you want to enable it, you should also make sure that the <tt>.mcglobald</tt> section is allocated on a page on its own by the linker script, and that the MMU is configured to mark such page as non-cached. <br />
<br />
The OS uses two software interrupts (6 and 7) and two hardware semaphores (0 and 1) of the MPC5668G to handle inter-core communication. They are initialised inside <code>StartOS()</code>. While all the other software interrupts and semaphores are available for user applications, those used by the OS should not be meddled with by user code. It is okay to briefly mask the interrupts with higher-priority interrupts or by disabling interrupts. In case of MPC5643L, as the microcontroller has two different interrupt controllers (one for each core), SW interrupt number 7 is used for both cores. Even if the MPC5643L has two SEMA4 modules, only the first module (the one associated to the master core) is used for this mechanism, this means that semaphores 0 and 1 of the first SEMA4 module are used for synchronisation (as in MPC5668G), while the remaining semaphores of the first SEMA4 module and all semaphores belonging to the second SEMA4 module are available for user applications.<br />
<br />
Examples of multicore applications are in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/ examples/ppc/dual_examples]</tt>. In particular, <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/mono_activate01/ examples/ppc/dual_examples/mono_activate01]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/multi_event01/ examples/ppc/dual_examples/multi_event01]</tt> are complete applications, nearer to real-world usage.<br />
<br />
Erika multicore for PowerPC supports AUTOSAR OS-like functionalities. For details please see the following page (but take into account that these features have not been published yet):<br />
[[Erika AUTOSAR OS]]<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for PPC e200 produces a Lauterbach Trace32 configuration file (<tt>t32.cmm</tt>) and a ORTI description file (<tt>system.orti</tt>) inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger, please issue <code>t32mppc</code> from the output directory. The ERIKA build system honors the <tt>T32SYS</tt> environment variable, if set.<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named <tt>start.sh</tt>) is produced in the output directory. To run the debugger, please issue <code>start.sh</code> from the output directory. The script creates two instances of the debugger, one for each core. For instace when MPC5668G is turned on, only the first (Z6) core is enabled. In order to simulate the real setup, the debugger connected to the second (Z0) core does not enable its core, but it is responsibility of the code running on the Z6 core to enable the Z0 core (this is different from the example script for MPC5668G distributed with the Lauterbach Trace32 software). Nonetheless, the startup script loads all the code and the debug symbols for both core and both debugger instances. In a typical debugging session, you start the execution of the code on the Z6 core from its debugger, and then, when the Z0 core has become active, start also the code on the Z0 core from the Z0 debugger. The barrier inside <code>StartOS()</code> comes handy to synchronize the code running on the two cores. The <tt>start.sh</tt> script runs only on Linux; currently the ERIKA build system does not support Windows to run Trace32 for e200 multicore systems. A similar approach has been adopted for MPC5643L.<br />
<br />
==Internals==<br />
<br />
===Interrupts===<br />
<br />
Interrupt handling in PPC e200 ERIKA uses software vector mode and a single entry point for all interrupts and exceptions, which is <code>EE_e200z7_irq()</code>. This function calls the user ISR and issues the end-of-interrupt for external interrupts; when the served interrupt is not nested, i.e., it interrupted a task directly, <code>EE_e200z7_irq()</code> also calls the scheduler before returning.<br />
<br />
This scheme of IRQ handling can be changed by rewriting the crt0 and changing the IVOR setup. In this way it is possible, for example, to use hardware vector mode. Please note that it is important that the end-of-interrupt be issued before calling the scheduler, as the scheduler may not return when a new task is to be scheduled.<br />
<br />
===Use of non volatile registers in Erika PowerPC===<br />
<br />
Some Erika RTOS assembly modules in PowerPC use non volatile registers for their internal purposes (r14-r31). Such modules are:<br />
<br />
* ee_e200zx_contex.S - This module is in charge of managing context switch for multistack on e200zx<br />
* ee_oo.S - This module is in charge of saving and restoring registers for Osek TerminateTask() on e200zx<br />
* ee_entry.S - This module handles exception entry points and hardware setup for the e200zx<br />
* ee_boot.S - This module represents boot sequence for PowerPC MCUs.<br />
<br />
The use of r14-r31 registers is limited, just few lines of code. But this information is relevant in case advanced features of some compilers are used, (e.g.: to define additional non-standard SDAs, Small Data Area). For instance Windriver Diab compiler has the REGISTER directive in the linker script to fullfill this requirement. If this non-standard approach is not required this information can be neglected. It is provided in order to give the position of such code whenever the use of non volatile registers (r14-r31) is necessary for non-standard purposes. For details please refere to your compiler documentation.<br />
<br />
Assumption for future development: additional SDA base address will be stored starting from register r14<br />
<br />
== Download and install of Eclipse, RT-Druid, and ERIKA source ==<br />
<br />
To build an ERIKA application you need:<br />
* ERIKA source code<br />
* RT-Druid and a hosting Eclipse<br />
* Some command-line tools<br />
<br />
=== ERIKA source code ===<br />
<br />
ERIKA source code is bundled with RT-Druid. ERIKA for PPC e200 honors the definition of '''ERIKA_FILES''', so you can use the latest version of ERIKA as explained in [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]].<br />
<br />
=== Eclipse and RT-Druid in one piece ===<br />
<br />
A complete version of an Eclipse installation together with the RT-Druid plugin can be downloaded from this page:<br />
http://erika.tuxfamily.org/erika-for-multiple-devices.html. Please make sure to use a version not older than 1.6.0 beta. See also [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application]].<br />
<br />
=== Eclipse and RT-Druid piece by piece ===<br />
<br />
Alternatively, if you already have a copy of Eclipse or you want to use a version of Eclipse different from the one provided by the page above, you can follow this procedure.<br />
* To download the e200 plug-in for Eclipse refer the following site: [http://download.tuxfamily.org/erika/webdownload/rtdruid_beta Plug-in download site].<br />
Procedure for installation:<br />
* Step 0:<br />
: Get ''Eclipse'' and required plug-ins;<br />
: Where possible, the suggestion is to download the ''all in one update site'' and use the eclipse update manager or to use the eclipse update manager directly on a web site;<br />
:* Eclipse<br />
:: If you don't have any eclipse installations, you can download eclipse with cdt already installed from [http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/heliossr1 Eclipse IDE for C/C++].<br />
:: It is also possible use an already installed distribution of eclipse or to download one (for example from [http://www.eclipse.org/downloads Eclipse Downloads]) and then add all missing plug-ins.<br />
:* EMF<br />
:: The main page to download EMF is [http://www.eclipse.org/modeling/emf/downloads/?project=emf Eclipse Modeling Framework].<br />
:: The version to download is related to the eclipse version: eclipse 3.3 -> emf 2.3 , eclipse 3.4 -> emf 2.4, eclipse 3.5 -> emf 2.5, eclipse 3.6 -> emf 2.6. <br />
:: The list of required plugins is:<br />
::: org.eclipse.emf.common<br />
::: org.eclipse.emf.ecore<br />
::: org.eclipse.emf.edit<br />
::: org.eclipse.emf.common.ui<br />
::: org.eclipse.emf.edit.ui<br />
:: Clearly it is possible to install more plugins, like the whole emf runtime or sdk<br />
:* CDT<br />
:: The main page to download CDT is [http://www.eclipse.org/cdt/downloads.php CDT Downloads].<br />
:: Also here, the version to download is related to eclipse version. <br />
:: In this case is required only the cdt runtime plugin.<br />
: [http://erika.tuxfamily.org/forum/viewtopic.php?f=6&t=651&sid=89784e2d97765c3f1c41f6e3c049437a#p727 Forum Post (in italian) about installing the Eclipse plugins]<br />
* Step 1:<br />
: Open ''Eclipse'';<br />
: From the menu ''Help'' select ''Install New Software...'';<br />
: Add with the button ''Add...'' the reference site mentioned above (fill the Location field with this: http://download.tuxfamily.org/erika/webdownload/rtdruid_beta);<br />
: Tick all plug-ins related to RT-Druid core and to Erika Enterprise, then click on the button ''Next'' to install them;<br />
: Restart Eclipse;<br />
* Step 2:<br />
: From the menu ''File'' select ''New'' and then RT-Druid Oil and C/C++ Project;<br />
: From the Project menu select one of the available e200 demo tests;<br />
: Then click on the project name with the right mouse button and build to obtain the elf object module for debugging;<br />
<br />
=== Additional software ===<br />
<br />
ERIKA uses GNU make and some command-line utilities to build programs. You need the following tools (please notice that only the less common commands are listed here; very common commands that are present in any Unix/POSIX system like ''ls'' are not listed for simplicity):<br />
* make (GNU version)<br />
* gawk (GNU AWK)<br />
* sed<br />
* grep<br />
<br />
For Linux the above commands are present in virtually every standard installation; but you can always install them from the respective packages of your distributions.<br />
<br />
For Windows, [http://www.cygwin.com/ Cygwin] is recommended. Please make sure to include the above packages (package names are the same as the tool names).<br />
<br />
== HOWTOs ==<br />
* [[How to create, compile and debug an application for Freescale MPC5674F]]<br />
* [[How to run the MODISTARC regression tests for Freescale MPC5674F]]<br />
<br />
<br />
[[Category:Supported Devices]]</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2014-07-14T11:00:05Z<p>Francesco: /* Multicore Autosar OS Support */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.2.0 (for both Single and Multicore).<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ Autosar]: two instances of the operating systems run on the two cores, and communication between cores is performed with a few APIs and shared memory.<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX[[#Compilers Notes|<sup>[a]</sup>]]<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
==== Compilers Notes ====<br />
* [a] RT-Druid support for Diab will be released ASAP.<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. See [[ERIKA multicore support]] for more details about multicore systems on Erika. Later in this page you will find a paragraph relative to specific multicore support developed for Tricore Aurix, according to '''Autosar OS 4.0 Rev 3''' specifications.<br />
<br />
Tricore AURIX support CPU clock configuration with a simple PLL driver. The target clock value in MHz can be set with the ''CPU_CLOCK''' field.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x family), is guaranteed to be perfectly matched.<br />
<br />
'''N.B.''' To get the real value set you can use '''EE_tc27x_get_clock()''' API after executing '''StartOS''', PLL configuration is done during OS start-up.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
=== MCU ===<br />
<br />
'''MCU_DATA''' support only the '''TC27x''' value. Compiler can be specified even in '''MCU_DATA''' block and will inherited by all configured CPUs (useful in multicore project configuration).<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
There is only support form TriBoard TC2x5 equiped with a TC275TE MCU. This board only provide debug interface and 8 leds, so the support is limited to the LEDs configuration/driving and, because standard ERIKA demos require it, an external button (''external'' means that have to be soldered by the user) mounted on pin P15.8 of TC275TE (corresponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector). Add the following OIL field to enable this support.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
Due to the special implementation of the Interrupt Vector in AURIX architecture, each entry of the vector table is simply identified by it's priority value. It must be the application code that configure the service request node (''SRN''') with the right priority, assigning in this way the right handler.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''PRIORITY''': The ISR priority that represent it's position inside Interrupt Vector so it has to be considered as ISR Identifier. The '''ENTRY''' field, the one usually used to declare Interrupt IDs, is still available but it's superfluous because it has to be equal to PRIORITY and, in any case, priority value take the precedence.<br />
*'''HANDLER''': Declare the interrupt handler symbol. If it's not declared the the handler symbol is supposed to be equal to ISR block name (IsrLow in the example).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x family don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
The only supported format for EEOPTs is a single name, which should be a valid C identifier (i.e., only Latin letters, digits, and underscore are allowed; the first character cannot be a digit). And any other format is not supported, and even if it works now, it may break in the future.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''EE_DEBUG''': Replace the often used DEBUG option (because it conflict with compilers DEBUG define). Enable debug compiler options, basically less optimization and debug symbols generation plus defualt TRAP handlers are implemented as busy loops instead of system reset.<br />
* '''EE_EXECUTE_FROM_RAM''': When specified, a linker script is used that maps both code and data in the RAM space. Executables produced with this option can be used only together with a debugger that loads the program in memory. By default, code and constant data are mapped to Flash, data to RAM.<br />
* '''EE_SAVE_TEMP_FILES''': Enable temporary files saving for the compiler, useful to debug build process and to inspect generate assembly code. It's useful only for HIGHTEC GCC compiler because for TASKING compiler is always active. For the GCC compiler it has been added the switch because the size of temporary files is '''huge'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
This feauture is automatically enabled by RT-Druid during the configuration generation step. To specify that a Resource is used by both a Task and a ISR you need to add that resource to the corrisponding ISR object as follows:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
The OSEK/VDX standard provides support for a '''System Counter''' (a counter that is automatically linked to a hardware timer). The System Timer is used to give a coherent timing reference across the entire application.<br />
<br />
In ERIKA Enterprise, this special counter has been named '''System Timer'''. To use it, you need to set a specific attribute in a Counter definition. Please note that only one counter '''for each core''' can be the System Timer.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''COUNTER/TYPE/DEVICE''' must be a valid device that can be used for a system timer. Currently, for TRICORE only '''STM''' (System Timer Module) MCU peripheral is a valid device for system timer. Both Interrupt source of this peripheral can be set to device and allowed values are '''STM_SR0''' and '''STM_SR1'''<br />
* '''COUNTER/TYPE/PRIORITY''' By default SYSTEM_TIMER is tied to smallest ISR priority (i.e. PRIORITY = 1;), but it can be overritten. Ovveride is necessay in multicore environment because priority 1 is used by the '''Intercore Interrupt Request'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
In addition to '''AUTOSAR OS Kernel Interface''', in ERIKA AURIX porting are implemented a bunch of utility functions that will be considered as part of '''ERIKA API'''. As usual they are separated in the three logical layer that compose ERIKA architecture abstraction: '''CPU, MCU & BOARD'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. In this layer are declared the functions to temporary disable '''ENDINIT''' and '''SAFETY_ENDINIT''' register protection (see Infineon AURIX documentation). These functions are a little bit tricky: ''declaration'' belong to CPU layer, because AURIX architecture documentation states that every AURIX implementation has some kind of '''ENDINIT''' and '''SAFETY_ENDINIT''' protection, but delegate implementation details to each AURIX family, so functions ''definitions'' has been done inside MCU files.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc27x_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc27x_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc27x_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc27x_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc27x_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for Infineon AURIX produces a Lauterbach Trace32 configuration file ('''t32.cmm''') and a ORTI description file ('''system.orti''') inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger for singlecore projects, please issue '''t32mtc''' from the output directory. The ERIKA build system honors the '''T32SYS''' environment variable, if set (default ''T32SYS ?= C:/T32'')<br />
<br />
=== Muticore Projects ===<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named '''tc27x_mc_start.sh''' under cygwin and linux or '''tc27x_mc_start.bat''' for Windows cmd) is produced in the output directory. If the build targeted AURIX Flash (the default behaviour), before executing debug you need to flash multicore images.<br />
To do that simply execute '''tc27x_mc_flash.sh''' (under Linux or Cygwin environment) or '''tc27x_mc_flash.bat''' (in Windows environment) scripts.<br />
<br />
To run the debugger, please issue ''tc27x_mc_start.[sh,bat]'' from the output directory. The script creates up to three instances of the debugger, one for each core. Slave cores cannot be started until master core (Core 0) enable them, thing that is made early in start-up code. Nonetheless, the startup script loads all the code and the debug symbols for each core and each debugger instances. The barrier inside '''StartOS()''' comes handy to synchronize the code running on the different cores.<br />
<br />
'''N.B.''' To let know the build system for wich Trace32 architecture (windows, windows64, pc_linux ecc.) it have to generate script for, set '''T32ARCH''' environment variable/pass it as make parameter with the right value (default ''T32ARCH ?= windows64'').<br />
<br />
== iSYSTEM winIDEA support ==<br />
<br />
ERIKA Enterprise is supported by iSYSTEM winIDEA. For more information about the ERIKA Enterprise support please chek the [http://www.isystem.com/supported-rtos/erika iSYSTEM - Erika webpage].<br />
<br />
For applications, based on an AUTOSAR/OSEK compliant OS such as ERIKA Enterprise, the OSEK Run-Time Interface (ORTI) file is a method for describing the structure of the RTOS to the debugger. By reading in the ORTI file generated by the RTDRUID when building an ERIKA-based application, the winIDEA debugger becomes ERIKA Enterprise OS-aware.<br />
<br />
ERIKA Enterprise OS awareness provides the following features:<br />
<br />
- Display of OS Resources and Status<br />
<br />
- Run-Time Analysis (Profiler Timeline) of Tasks and Interrupts (ISR Category 1 and 2)<br />
<br />
- Analysis of CPU Utilization (Profiler Statistics) of Tasks and Interrupts (ISR Category 1 and 2)<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
'''WARNING:''' For the release '''2.3.0''' the default configuration of project don't let you build the project as single .elf. To do that you need to change the target called by build system makefile.<br />
To do that open project '''properties->C/C++ Build->behaviour''' and '''delete the 'all' target''' from ''Build (Incremental build)''.<br />
<br />
= Additional Notes =<br />
<br />
Please note that the AURIX port has not been yet completely released on this website. Some of the components for an Autosar SC4 OS, like: Memory protection, Stack Monitoring, Timing Protection and Schedule Table are not released. If you need more information about the development status of this port please contact Evidence Srl.</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Freescale_PPC_e200_(MPC_56xx)Freescale PPC e200 (MPC 56xx)2014-07-14T10:58:33Z<p>Francesco: /* Multicore support */</p>
<hr />
<div>= Freescale PPC e200 (MPC 56xx) support =<br />
ERIKA Enterprise supports the PPC e200 family microcontrollers.<br />
The support for RT-Druid is available starting from release 1.5.0.<br />
The support includes: <br />
# Support MPC5674F (e200z7). MPC5668G (e200z6) is supported in version 1.6.0; version 1.6.1 will support both cores (z6 and z0) of the MPC5668G (already available on the [[ERIKA Enterprise and RT-Druid SVN Access|Subversion repository]]). Support for MPC5643L (e200z4).<br />
# Support for the WindRiver DIAB and Freescale CodeWarrior compilers.<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers<br />
** WindRiver DIAB C Compiler 5.5.1 and 5.8.0.<br />
** Freescale CodeWarrior:<br />
*** Windows: CodeWarrior Development Studio for MPC55xx/56xx 2.7<br />
*** Linux: CodeWarrior Development Studio for MCU 10.2<br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: Currently limited to the MPC5668G and MPC5643L, it follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ Autosar]: two instances of the operating systems run on the two cores, and communication between cores is performed with a few APIs and shared memory.<br />
<br />
* MMU Handling<br />
** Static global mappings to let all the application see all the memory/peripherals in the system; no memory protection is implemented and all the code is executed in supervisor mode.<br />
<br />
== Host Configuration ==<br />
<br />
* RT-Druid requires Java 1.6.<br />
* It is possible to use a version of ERIKA more recent than the one provided with RT-Druid; just download the ERIKA tree from the repository (see [[ERIKA Enterprise and RT-Druid SVN Access]]) and point the '''ERIKA_FILES''' environment variable to its location; see [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]] for some caveats.<br />
<br />
=== Wind River Diab ===<br />
* Compiler: The compiler commands (dcc, das, dld, and dar) are assumed to be reachable from the $PATH. If a specific version of them has to be used it must be specified in pkg/cfg/arch/cc_z7diab.mk<br />
* Operating system: The PPC e200 port has been developed under Debian testing/unstable as of May 2010; the only known requirement is Java 1.6 to run RT-Druid.<br />
* In the reference environment, the Diab toolchain was located in /opt/case/diabdata/<version> and Eclipse in /opt/eclipse. No hard requirement is made by the build system, as specified above. <br />
<br />
=== Freescale CodeWarrior ===<br />
*Compiler: The compiler directory can be specified using the environment variable '''PPC_CW_BASEDIR'''; this directory must contain the directories ''PA_Support'', and ''PA_Tools'' or ''PowerPC_EABI_Tools''. ERIKA makefiles find all the files they need with relatives paths from there. Please notice that makefiles require that the variable '''PPC_CW_BASEDIR''' do not contain any space. An evaluation or a limited version of the compiler can be downloaded from the [http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_DOWNLOADS Freescale Web site].<br />
*Operating system: both Linux and Windows are supported. CodeWarrior support has been developed under Debian Linux and Windows XP, but other (and more recent) versions should work. On Windows, ''Special Edition: CodeWarrior for Microcontrollers 10.5'' is currently used, and on Linux ''CodeWarrior Development Studio for MCU'' version 10.2. On Windows the Cygwin environment is used for ERIKA makefiles, so the '''PPC_CW_BASEDIR''' variable must use forward slashes '/' and must not contain spaces; you can always convert the path with the ''cygpath'' command. For example, in this case the value to use is <code>/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7</code>:<br />
$ cygpath.exe `cygpath.exe -ms "/c/Program Files/Freescale/CW for MPC55xx and MPC56xx 2.7"`<br />
/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7<br />
*OIL file: Currently, an ''EEOPT'' with value '''"__CODEWARRIOR__"''' must be specified in the OIL file. See [[#OIL file configuration]] for more details.<br />
<br />
== Target configuration and programming==<br />
<br />
* ERIKA is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]<br />
* ERIKA supports the Freescale MPC5674F, MPC5668G and MPC5643L MCUs (we have been able to run it on an MPC56XX and others; Freescale MCUs are really very similar).<br />
* At system boot the interrupt controller is set up to work in Software Vector Mode, and all the interrupts are associated to default handlers. The kernel does not use any specific device/interrupts, although for testing purposes it is possible to use the decrementer and some gpios as interrupt sources. All the code is executed from flash, all the data sections are loaded into the SRAM at boot time (the MMU is configured to provide 1:1 mappings for code running in system mode for all the sensible regions, like flash, sram and device registers).<br />
* The version in the repository supports both FLE and VLE modes.<br />
* The scripts generated by the build process are compatible with Lauterbach v200912. The commands generated to setup the NEXUS port are not compatible with older releases of the Lauterbach software. In case you hit this problem, remove the NEXUS.* lines from the generated scripts, ad set up the port according to the Lauterbach version you are using.<br />
* Target registers are used according the PPC ABI described in the DIAB manual.<br />
* The stack fill pattern is configurable at compile time, but is assumed to be 0xa5.<br />
* For Osek conformance classes, which support TerminateTask(), each running task requires 96 bytes of stack. <br />
For multistack configurations, 76 bytes are required on each stack for context switching. You can add this numbers to the requirements of your application to estimate task usage.<br />
* Stack pointer is aligned at 16 byte (fixed in version 1.6)<br />
<br />
=== MCUs ===<br />
* The MCUs supported are currently the following:<br />
** MPC5674F (Mamba)<br />
** MPC5668G (Fado)<br />
** MPC5643L (Leopard)<br />
<br />
===OIL file configuration===<br />
For more information about configuration through OIL file, see [[Tutorial: RT-Druid and OIL basics]]. Here only the e200zX-specific part of OIL is described.<br />
;CPU (CPU_DATA)<br />
: CPU must be set to E200ZX. The exact model is specified with the '''MODEL''' item (supported values are '''E200Z0''', '''E200Z6''' , '''E200Z7''' and '''E200Z4'''. Generation of VLE code can be selected by setting '''VLE''' to '''TRUE'''; please notice that all the application and the OS code must have the same setting, as ERIKA makefiles do not support mixed programs. Size in byte of the shared stack can be specified with the optional '''SYS_STACK_SIZE''' item.<br />
: Example of a CPU_DATA section:<br />
CPU_DATA = PPCE200ZX {<br />
ID = "MainCpu";<br />
MODEL = E200Z7;<br />
APP_SRC = "main.c";<br />
MULTI_STACK = FALSE;<br />
VLE = FALSE;<br />
SYS_STACK_SIZE = 512;<br />
};<br />
:On multicore systems, one CPU_DATA instance can exist for each core. They must have different '''ID'''s. See [[ERIKA multicore support]] for more details about multicore systems on Erika.<br />
;MCU<br />
: MCU support is present for MPC5674F ,MPC5668G and MPC5643L. The only item supported is '''MODEL''', which can be either '''MPC5674F''', '''MPC5668G''' or '''MPC5643L'''. Most of the differences produced by this setting affect memory map and Lauterbach scripts.<br />
: Example:<br />
MCU_DATA = PPCE200ZX {<br />
MODEL = MPC5674F;<br />
};<br />
;System Timer<br />
Erika on PowerPC has a system timer based on PowerPC Decrementer. This feature is available for all supported MCUs: MPC5674F (Mamba), MPC5668G(Fado) and MPC5643L (Leopard). System time also requires CPU_CLOCK field to be set on CPU_DATA, hence CPU_CLOCK value must be added in CPU_DATA configuration to have a system timer configured.<br />
This is an example to configure Decrementer as System Timer:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_DECREMENTER";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "DECREMENTER";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
<br />
Furthermore for MPC5643L (Leopard) is available a system timer based on Freescale STM (System Timer Module), that is a device available in several Freescale PowerPC MCUs. In this case the following configuration must be take into account:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_STM";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
...<br />
...<br />
<br />
<br />
;EEOPTs<br />
: See also [[EEOPT]] for common EEOPTs.<br />
: Special options for the PPC e200 ERIKA porting can be specified through '''EE_OPT''' items in the '''OS''' section (please notice that the value for an '''EE_OPT''' is a string, so double quotes (") must be added around the values in this list.<br />
:; EE_SYSTEM_TIMER_DEVICE_DECREMENTER (see system timer section above)<br />
:; EE_SYSTEM_TIMER_DEVICE_STM (available only for MPC5643L, see system timer section above)<br />
:;EE_ISR_DYNAMIC_TABLE<br />
::Used to enable dynamic ISR table support that let register ISR handlers at runtime calling <code>EE_e200z7_register_ISR</code>.<br />
:;__E200ZX_EXECUTE_FROM_RAM__<br />
:: When specified, a linker script is used that maps both code and data in the RAM space. Executables produced with this option can be used only together with a debugger that loads the program in memory. By default, code and constant data are mapped to Flash, data to RAM.<br />
:;__CODEWARRIOR__<br />
:: Invoke Freescale CodeWarrior compiler. See [[#Freescale CodeWarrior]] for information on how to configure the compiler. The default compiler is Wind River Diab; see [[#Wind River Diab]] for configuration.<br />
:;__USE_CUSTOM_LINKER_SCRIPT__<br />
:: Don't use the dafault linker script. Users can direct the linker to use their own linker script by setting the <code>LDFLAGS</code> variable. Example:<br />
OS EE {<br />
EE_OPT = "__USE_CUSTOM_LINKER_SCRIPT__";<br />
LDFLAGS = "../my_linker_script.ld";<br />
};<br />
:;__USE_CUSTOM_CRT0__<br />
:: Don't use Erika default crt0. Users can provide their own crt0 by adding source files in the usual way (APP_SRC in the OIL file).<br />
;;__MINIMAL_CC_OPTIONS__<br />
:: Enable only the compiler flags absolutely needed to compile Erika, so users can easily add their preferences in CFLAGS.<br />
;;__EE_USE_MMU__<br />
:: Enable the MMU support. The MMU can be configured by calling <code>EE_e200zx_mmu_setup()</code>. See the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> for more details. An example configuration can be found in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt>.<br />
;;__EE_CRT0_INIT_MMU__<br />
:: Initialize the MMU from the crt0. See <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt> for an example, and the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt>.<br />
;;EE_NO_LIBEE<br />
:: To not generete the kernel library '''libee.a''' but link all the objects files (kernel + application) directly in an elf file. This option is useful to try Erika with CodeWarrior compiler with an evaluation license, because the archiver is not enabled with this license.<br />
;;DEBUG<br />
:: On this architecture, enabling debug symbols does not inhibit optimization.<br />
;;MPC5643L_STD_SW_MMU_CONFIG"<br />
:: This EE_OPT is valid only for MPC5643L (Leopard) and provides a standard (and in most cases sufficient) MMU configuration. This option is useful expecially running your code from FLASH where Debugger does not initializes the MMU for you.<br />
;;EE_LAUTERBACH_DEMO_SIM<br />
:: This option is available only for Mamba (MPC5674F), for details please take a look at DEMO_ErikaSim in the directory of templates. It causes the generation of Lauterbach scripts to use with Lauterbach simulator.<br />
<br />
There are a few examples in the ERIKA code base that can be used as a starting point for new projects. Examples include also a makefile, which can be used to compile a project without a need of an IDE. The makefile runs RT-Druid non-interactively, and requires the environment variable '''RTDRUID_ECLIPSE_HOME''' to point to the Eclipse directory where RT-Druid is installed.<br />
<br />
Examples can be accessed as templates in RT-Druid (see [[How to create, compile and debug an application for Freescale MPC5674F]]), or directly in the source code: [http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/ examples/ppc/].<br />
<br />
In the first version of ERIKA and RT-Druid supporting e200zX, the only e200-specific setting in the OIL configuration file was the CPU_DATA value, which had to be set to '''MPC5674F''' instead of '''PPCE200ZX'''. This not supported any more.<br />
<br />
=== APIs ===<br />
* List of functions (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_irq.h?view=markup pkg/cpu/e200zx/inc/ee_irq.h]</tt> for prototypes and other details):<br />
** EE_e200z7_register_ISR(level, handler, priority): Associate <tt>handler</tt> to the IRQ <tt>level</tt>, with the given <tt>priority</tt> (available only if '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' is set).<br />
** EE_e200z7_setup_decrementer(delay): Configure the decrementer to raise an interrupt every <tt>delay</tt> cycles.<br />
** EE_e200z7_setup_decrementer_oneshot(delay): Configure the decrementer to raise an interrupt <tt>delay</tt> cycles after invocation.<br />
** EE_e200z7_stop_decrementer(): Stop the decrementer from generating interrupts.<br />
** EE_e200zx_setup_fixed_intv(bitpos): Enable the fixed-interval interrupt.<br />
** EE_e200zx_stop_fixed_intv(): Disable the fixed-interval interrupt.<br />
** EE_e200zx_mmu_setup(entries, count): MMU initialization.<br />
<br />
Note: notice that the *_e200z7_* is slightly misleading since it seem to refer only to e200z7 family, it is a legacy name convention when the only supported architecture by Erika was Z7. Currently even Z0, Z4 and Z6 are supported hence these functions can be used for such architectures, although it refers to *_e200z7_*.<br />
<br />
====Interrupts====<br />
<br />
There are two way to configure ISR. The standard way is the static way with OIL configuration (example):<br />
<br />
ISR DecrIsr {<br />
CATEGORY = 2;<br />
ENTRY = "DECREMENTER";<br />
};<br />
<br />
ISR FixedIntvIsr {<br />
CATEGORY = 2;<br />
ENTRY = "FIXED_INTV";<br />
HANDLER = "fixed_intv_handler";<br />
};<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
ENTRY = "0";<br />
};<br />
ISR IsrMedium {<br />
CATEGORY = 2;<br />
PRIORITY = 2;<br />
ENTRY = "1";<br />
};<br />
<br />
ISR IsrHigh {<br />
CATEGORY = ;<br />
PRIORITY = 3;<br />
ENTRY = "2";<br />
HANDLER = "isr_high_handler";<br />
};<br />
<br />
In static ISR table handling mode there's full support for both ISR1 and ISR2 for '''external interrupt'''. To register an handler you should use the suitable macro ('''ISR1''' or '''ISR2''') passing the value of '''HANDLER''' field or the '''ISR name''', in case the former is missing. The configuration field '''ENTRY''' declare the position of the handler inside the vector table (the example show three handlers that get the first three positions in vector, corrisponding to the first three software interrupt request). Priority field corripsond to interrupt priority value set to corrisponding Interrupt Controller Priority select registers ('''INTC.PSR[(ENTRY)] = PRIORITY'''), the values have to be inside [0..15] range.<br />
<br />
There is direct support for two cpu '''internal exceptions''', those generated by the time base facilities: decrementer and fixed interval timer ('''ENTRY = "DECREMENTER"''' and '''ENTRY = "FIXED_INTV"'''' respectively.). Support for Watch-Dog timer will be added. To register an handler for internal interrupt you have to use '''ISR1_INT''' or '''ISR2_INT''' (two different couple of macros are needed to issue EOI, End Of Interrupt, only for external interrupts). Priority field in configuration have no meaning for internal interrupts.<br />
<br />
You can register handler by code dinamically with with the <code>EE_e200z7_register_ISR()</code> described above. To enable dynamic ISR table support you must declare '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' configuration OIL file. The '''first 16 level''' of dynamic table are reserved for '''internal exceptions''' handlers, so you have to add this offset to the '''ENTRY''' value of the static approach to register an handler to the same interrupt source.<br />
<br />
ISRs (Interrupt Service Routines) are just void functions with no arguments. For external interrupts (IVOR4), the EOI (End Of Interrupt) is issued by ERIKA's handler; user ISRs need not bother about that.<br />
<br />
====Multicore support (MPC5668 and MPC5643L)====<br />
* Functions used for multicore support on MPC5668 (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5668/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5668/inc/ee_dual.h]</tt> for prototypes and other details):<br />
** EE_mpc5668_start_z0(f): Enable the z0 CPU.<br />
<br />
The same paradigm of multicore support available for MPC5668G, is also available for the MPC5643L, (for details see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5643l/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5643l/inc/ee_dual.h]</tt>). Likewise MPC5668G, in order to start the slave core, a EE_mpc5643l_start_slave(f) call has to be provided at startup (typically in main function) immediately before the StartOS().<br />
<br />
=== Boards ===<br />
* ERIKA has been developed on an '''Axiom MPC5674evbfxmb evaluation board'''. This evaluation board has the MAMBA microcontroller (Freescale MPC5674F)<br />
** The kernel has no dependency on the board itself, but some of its functionalities can be used for debugging purposes. Including file "pkg/board/axiom_mpc5674fxmb/inc/ee_board.h" the following functions can be used:<br />
*** EE_leds_init(): which sets up the GPIOs associated with the leds.<br />
*** EE_EE_leds(mask): which turns the i-th led on or off depending on the state of the i-th bit in the mask passed as an argument.<br />
*** EE_led_<X>_on()/EE_led_<X>_off(): turns led X on or off.<br />
*** EE_buttons_disable_interrupts(button): disables the interrupt associated to the given button.<br />
*** EE_buttons_enable_interrupts(button): enables it.<br />
*** EE_buttons_clear_ISRflag(button): acknowledges the interrupt coming from the given button.<br />
*** EE_button_get_B<X>(): gets the status of button X.<br />
*** EE_buttons_init(): initializes the GPIOs associated to buttons.<br />
** The functions above are available if, respectively, __USE_LEDS__ and __USE_BUTTONS__ are defined upon inclusion of ee_board.h<br />
** The connections are assumed to be the following:<br />
*** GPIO 147-150: connected to LED0-3. Looking at the pins on the EVB:<br />
**** ETPUB1 -> USER_LED1<br />
**** ETPUB2 -> USER_LED2<br />
**** ETPUB3 -> USER_LED3<br />
*** GPIO 450: connected to BUTTON0 (ETPUC9 -> USER_DEV1)<br />
<br />
* Erika is available for the '''Freescale MPC5668EVB Evaluation Board'''. This evaluation board has the FADO microcontroller (Freescale MPC5668G)<br />
** for this board the are no available support for leds or buttons.<br />
<br />
* Erika is available for '''Freescale MPC564xLEVB Evaluation Board'''. This evaluation board has the LEOPARD microcontroller (Freescale MPC5643L)<br />
** for this board there is the same set of primitives defined for "Axiom MPC5674evbfxmb" board, hence a basic support for leds and button is available.<br />
<br />
== Multicore support ==<br />
<br />
In the ERIKA multicore support for PPC e200 there are a few aspects specific to the PPC e200 architecture, and they are described here. Please refer to [[ERIKA multicore support]] for general information on ERIKA multicore systems.<br />
<br />
The PPC evaluation board supported by Erika Multicore is the Freescale MPC5668G/E Evaluation kit, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5668GKIT. The multicore support is also provided for MPC5643L with the Freescale evaluation board MPC564xL EVB, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=XKT564L.<br />
<br />
In multicore configuration, is it possible running both instances of the operating system both in RAM and Flash. For instance on MPC5668G, the internal SRAM is partitioned statically in two: memory from 0x40000000 to 0x4001FFFF is reserved to the first core and shared variables, while memory from 0x40020000 to 0x4003FFFF is reserved to the second core. 0x40020000 is used as the starting address of the second core. A similar approach is available for MPC5643L. In order to customize such memory assignments please refer to memory0.ld and memory1.ld files in "erika/pkg/mcu/freescale_mpc56XX/cfg/multicore" (where XX=43l for Leopard and XX=68 for Fado).<br />
<br />
Shared variable data is allocated in a single section (<tt>.mcglobald</tt>). Access to this section must be performed without cache, or the OS may malfunction. ERIKA crt0 does not enable cache; if you want to enable it, you should also make sure that the <tt>.mcglobald</tt> section is allocated on a page on its own by the linker script, and that the MMU is configured to mark such page as non-cached. <br />
<br />
The OS uses two software interrupts (6 and 7) and two hardware semaphores (0 and 1) of the MPC5668G to handle inter-core communication. They are initialised inside <code>StartOS()</code>. While all the other software interrupts and semaphores are available for user applications, those used by the OS should not be meddled with by user code. It is okay to briefly mask the interrupts with higher-priority interrupts or by disabling interrupts. In case of MPC5643L, as the microcontroller has two different interrupt controllers (one for each core), SW interrupt number 7 is used for both cores. Even if the MPC5643L has two SEMA4 modules, only the first module (the one associated to the master core) is used for this mechanism, this means that semaphores 0 and 1 of the first SEMA4 module are used for synchronisation (as in MPC5668G), while the remaining semaphores of the first SEMA4 module and all semaphores belonging to the second SEMA4 module are available for user applications.<br />
<br />
Examples of multicore applications are in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/ examples/ppc/dual_examples]</tt>. In particular, <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/mono_activate01/ examples/ppc/dual_examples/mono_activate01]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/multi_event01/ examples/ppc/dual_examples/multi_event01]</tt> are complete applications, nearer to real-world usage.<br />
<br />
Erika multicore for PowerPC supports AUTOSAR OS-like functionalities. For details please see the following page (but take into account that these features have not been published yet):<br />
[[Erika AUTOSAR OS]]<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for PPC e200 produces a Lauterbach Trace32 configuration file (<tt>t32.cmm</tt>) and a ORTI description file (<tt>system.orti</tt>) inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger, please issue <code>t32mppc</code> from the output directory. The ERIKA build system honors the <tt>T32SYS</tt> environment variable, if set.<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named <tt>start.sh</tt>) is produced in the output directory. To run the debugger, please issue <code>start.sh</code> from the output directory. The script creates two instances of the debugger, one for each core. For instace when MPC5668G is turned on, only the first (Z6) core is enabled. In order to simulate the real setup, the debugger connected to the second (Z0) core does not enable its core, but it is responsibility of the code running on the Z6 core to enable the Z0 core (this is different from the example script for MPC5668G distributed with the Lauterbach Trace32 software). Nonetheless, the startup script loads all the code and the debug symbols for both core and both debugger instances. In a typical debugging session, you start the execution of the code on the Z6 core from its debugger, and then, when the Z0 core has become active, start also the code on the Z0 core from the Z0 debugger. The barrier inside <code>StartOS()</code> comes handy to synchronize the code running on the two cores. The <tt>start.sh</tt> script runs only on Linux; currently the ERIKA build system does not support Windows to run Trace32 for e200 multicore systems. A similar approach has been adopted for MPC5643L.<br />
<br />
==Internals==<br />
<br />
===Interrupts===<br />
<br />
Interrupt handling in PPC e200 ERIKA uses software vector mode and a single entry point for all interrupts and exceptions, which is <code>EE_e200z7_irq()</code>. This function calls the user ISR and issues the end-of-interrupt for external interrupts; when the served interrupt is not nested, i.e., it interrupted a task directly, <code>EE_e200z7_irq()</code> also calls the scheduler before returning.<br />
<br />
This scheme of IRQ handling can be changed by rewriting the crt0 and changing the IVOR setup. In this way it is possible, for example, to use hardware vector mode. Please note that it is important that the end-of-interrupt be issued before calling the scheduler, as the scheduler may not return when a new task is to be scheduled.<br />
<br />
== Download and install of Eclipse, RT-Druid, and ERIKA source ==<br />
<br />
To build an ERIKA application you need:<br />
* ERIKA source code<br />
* RT-Druid and a hosting Eclipse<br />
* Some command-line tools<br />
<br />
=== ERIKA source code ===<br />
<br />
ERIKA source code is bundled with RT-Druid. ERIKA for PPC e200 honors the definition of '''ERIKA_FILES''', so you can use the latest version of ERIKA as explained in [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]].<br />
<br />
=== Eclipse and RT-Druid in one piece ===<br />
<br />
A complete version of an Eclipse installation together with the RT-Druid plugin can be downloaded from this page:<br />
http://erika.tuxfamily.org/erika-for-multiple-devices.html. Please make sure to use a version not older than 1.6.0 beta. See also [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application]].<br />
<br />
=== Eclipse and RT-Druid piece by piece ===<br />
<br />
Alternatively, if you already have a copy of Eclipse or you want to use a version of Eclipse different from the one provided by the page above, you can follow this procedure.<br />
* To download the e200 plug-in for Eclipse refer the following site: [http://download.tuxfamily.org/erika/webdownload/rtdruid_beta Plug-in download site].<br />
Procedure for installation:<br />
* Step 0:<br />
: Get ''Eclipse'' and required plug-ins;<br />
: Where possible, the suggestion is to download the ''all in one update site'' and use the eclipse update manager or to use the eclipse update manager directly on a web site;<br />
:* Eclipse<br />
:: If you don't have any eclipse installations, you can download eclipse with cdt already installed from [http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/heliossr1 Eclipse IDE for C/C++].<br />
:: It is also possible use an already installed distribution of eclipse or to download one (for example from [http://www.eclipse.org/downloads Eclipse Downloads]) and then add all missing plug-ins.<br />
:* EMF<br />
:: The main page to download EMF is [http://www.eclipse.org/modeling/emf/downloads/?project=emf Eclipse Modeling Framework].<br />
:: The version to download is related to the eclipse version: eclipse 3.3 -> emf 2.3 , eclipse 3.4 -> emf 2.4, eclipse 3.5 -> emf 2.5, eclipse 3.6 -> emf 2.6. <br />
:: The list of required plugins is:<br />
::: org.eclipse.emf.common<br />
::: org.eclipse.emf.ecore<br />
::: org.eclipse.emf.edit<br />
::: org.eclipse.emf.common.ui<br />
::: org.eclipse.emf.edit.ui<br />
:: Clearly it is possible to install more plugins, like the whole emf runtime or sdk<br />
:* CDT<br />
:: The main page to download CDT is [http://www.eclipse.org/cdt/downloads.php CDT Downloads].<br />
:: Also here, the version to download is related to eclipse version. <br />
:: In this case is required only the cdt runtime plugin.<br />
: [http://erika.tuxfamily.org/forum/viewtopic.php?f=6&t=651&sid=89784e2d97765c3f1c41f6e3c049437a#p727 Forum Post (in italian) about installing the Eclipse plugins]<br />
* Step 1:<br />
: Open ''Eclipse'';<br />
: From the menu ''Help'' select ''Install New Software...'';<br />
: Add with the button ''Add...'' the reference site mentioned above (fill the Location field with this: http://download.tuxfamily.org/erika/webdownload/rtdruid_beta);<br />
: Tick all plug-ins related to RT-Druid core and to Erika Enterprise, then click on the button ''Next'' to install them;<br />
: Restart Eclipse;<br />
* Step 2:<br />
: From the menu ''File'' select ''New'' and then RT-Druid Oil and C/C++ Project;<br />
: From the Project menu select one of the available e200 demo tests;<br />
: Then click on the project name with the right mouse button and build to obtain the elf object module for debugging;<br />
<br />
=== Additional software ===<br />
<br />
ERIKA uses GNU make and some command-line utilities to build programs. You need the following tools (please notice that only the less common commands are listed here; very common commands that are present in any Unix/POSIX system like ''ls'' are not listed for simplicity):<br />
* make (GNU version)<br />
* gawk (GNU AWK)<br />
* sed<br />
* grep<br />
<br />
For Linux the above commands are present in virtually every standard installation; but you can always install them from the respective packages of your distributions.<br />
<br />
For Windows, [http://www.cygwin.com/ Cygwin] is recommended. Please make sure to include the above packages (package names are the same as the tool names).<br />
<br />
== HOWTOs ==<br />
* [[How to create, compile and debug an application for Freescale MPC5674F]]<br />
* [[How to run the MODISTARC regression tests for Freescale MPC5674F]]<br />
<br />
<br />
[[Category:Supported Devices]]</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Freescale_PPC_e200_(MPC_56xx)Freescale PPC e200 (MPC 56xx)2014-07-14T10:57:38Z<p>Francesco: /* Multicore support */</p>
<hr />
<div>= Freescale PPC e200 (MPC 56xx) support =<br />
ERIKA Enterprise supports the PPC e200 family microcontrollers.<br />
The support for RT-Druid is available starting from release 1.5.0.<br />
The support includes: <br />
# Support MPC5674F (e200z7). MPC5668G (e200z6) is supported in version 1.6.0; version 1.6.1 will support both cores (z6 and z0) of the MPC5668G (already available on the [[ERIKA Enterprise and RT-Druid SVN Access|Subversion repository]]). Support for MPC5643L (e200z4).<br />
# Support for the WindRiver DIAB and Freescale CodeWarrior compilers.<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers<br />
** WindRiver DIAB C Compiler 5.5.1 and 5.8.0.<br />
** Freescale CodeWarrior:<br />
*** Windows: CodeWarrior Development Studio for MPC55xx/56xx 2.7<br />
*** Linux: CodeWarrior Development Studio for MCU 10.2<br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: Currently limited to the MPC5668G and MPC5643L, it follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ Autosar]: two instances of the operating systems run on the two cores, and communication between cores is performed with a few APIs and shared memory.<br />
<br />
* MMU Handling<br />
** Static global mappings to let all the application see all the memory/peripherals in the system; no memory protection is implemented and all the code is executed in supervisor mode.<br />
<br />
== Host Configuration ==<br />
<br />
* RT-Druid requires Java 1.6.<br />
* It is possible to use a version of ERIKA more recent than the one provided with RT-Druid; just download the ERIKA tree from the repository (see [[ERIKA Enterprise and RT-Druid SVN Access]]) and point the '''ERIKA_FILES''' environment variable to its location; see [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]] for some caveats.<br />
<br />
=== Wind River Diab ===<br />
* Compiler: The compiler commands (dcc, das, dld, and dar) are assumed to be reachable from the $PATH. If a specific version of them has to be used it must be specified in pkg/cfg/arch/cc_z7diab.mk<br />
* Operating system: The PPC e200 port has been developed under Debian testing/unstable as of May 2010; the only known requirement is Java 1.6 to run RT-Druid.<br />
* In the reference environment, the Diab toolchain was located in /opt/case/diabdata/<version> and Eclipse in /opt/eclipse. No hard requirement is made by the build system, as specified above. <br />
<br />
=== Freescale CodeWarrior ===<br />
*Compiler: The compiler directory can be specified using the environment variable '''PPC_CW_BASEDIR'''; this directory must contain the directories ''PA_Support'', and ''PA_Tools'' or ''PowerPC_EABI_Tools''. ERIKA makefiles find all the files they need with relatives paths from there. Please notice that makefiles require that the variable '''PPC_CW_BASEDIR''' do not contain any space. An evaluation or a limited version of the compiler can be downloaded from the [http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_DOWNLOADS Freescale Web site].<br />
*Operating system: both Linux and Windows are supported. CodeWarrior support has been developed under Debian Linux and Windows XP, but other (and more recent) versions should work. On Windows, ''Special Edition: CodeWarrior for Microcontrollers 10.5'' is currently used, and on Linux ''CodeWarrior Development Studio for MCU'' version 10.2. On Windows the Cygwin environment is used for ERIKA makefiles, so the '''PPC_CW_BASEDIR''' variable must use forward slashes '/' and must not contain spaces; you can always convert the path with the ''cygpath'' command. For example, in this case the value to use is <code>/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7</code>:<br />
$ cygpath.exe `cygpath.exe -ms "/c/Program Files/Freescale/CW for MPC55xx and MPC56xx 2.7"`<br />
/cygdrive/c/PROGRA~1/FREESC~1/CWFORM~1.7<br />
*OIL file: Currently, an ''EEOPT'' with value '''"__CODEWARRIOR__"''' must be specified in the OIL file. See [[#OIL file configuration]] for more details.<br />
<br />
== Target configuration and programming==<br />
<br />
* ERIKA is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]<br />
* ERIKA supports the Freescale MPC5674F, MPC5668G and MPC5643L MCUs (we have been able to run it on an MPC56XX and others; Freescale MCUs are really very similar).<br />
* At system boot the interrupt controller is set up to work in Software Vector Mode, and all the interrupts are associated to default handlers. The kernel does not use any specific device/interrupts, although for testing purposes it is possible to use the decrementer and some gpios as interrupt sources. All the code is executed from flash, all the data sections are loaded into the SRAM at boot time (the MMU is configured to provide 1:1 mappings for code running in system mode for all the sensible regions, like flash, sram and device registers).<br />
* The version in the repository supports both FLE and VLE modes.<br />
* The scripts generated by the build process are compatible with Lauterbach v200912. The commands generated to setup the NEXUS port are not compatible with older releases of the Lauterbach software. In case you hit this problem, remove the NEXUS.* lines from the generated scripts, ad set up the port according to the Lauterbach version you are using.<br />
* Target registers are used according the PPC ABI described in the DIAB manual.<br />
* The stack fill pattern is configurable at compile time, but is assumed to be 0xa5.<br />
* For Osek conformance classes, which support TerminateTask(), each running task requires 96 bytes of stack. <br />
For multistack configurations, 76 bytes are required on each stack for context switching. You can add this numbers to the requirements of your application to estimate task usage.<br />
* Stack pointer is aligned at 16 byte (fixed in version 1.6)<br />
<br />
=== MCUs ===<br />
* The MCUs supported are currently the following:<br />
** MPC5674F (Mamba)<br />
** MPC5668G (Fado)<br />
** MPC5643L (Leopard)<br />
<br />
===OIL file configuration===<br />
For more information about configuration through OIL file, see [[Tutorial: RT-Druid and OIL basics]]. Here only the e200zX-specific part of OIL is described.<br />
;CPU (CPU_DATA)<br />
: CPU must be set to E200ZX. The exact model is specified with the '''MODEL''' item (supported values are '''E200Z0''', '''E200Z6''' , '''E200Z7''' and '''E200Z4'''. Generation of VLE code can be selected by setting '''VLE''' to '''TRUE'''; please notice that all the application and the OS code must have the same setting, as ERIKA makefiles do not support mixed programs. Size in byte of the shared stack can be specified with the optional '''SYS_STACK_SIZE''' item.<br />
: Example of a CPU_DATA section:<br />
CPU_DATA = PPCE200ZX {<br />
ID = "MainCpu";<br />
MODEL = E200Z7;<br />
APP_SRC = "main.c";<br />
MULTI_STACK = FALSE;<br />
VLE = FALSE;<br />
SYS_STACK_SIZE = 512;<br />
};<br />
:On multicore systems, one CPU_DATA instance can exist for each core. They must have different '''ID'''s. See [[ERIKA multicore support]] for more details about multicore systems on Erika.<br />
;MCU<br />
: MCU support is present for MPC5674F ,MPC5668G and MPC5643L. The only item supported is '''MODEL''', which can be either '''MPC5674F''', '''MPC5668G''' or '''MPC5643L'''. Most of the differences produced by this setting affect memory map and Lauterbach scripts.<br />
: Example:<br />
MCU_DATA = PPCE200ZX {<br />
MODEL = MPC5674F;<br />
};<br />
;System Timer<br />
Erika on PowerPC has a system timer based on PowerPC Decrementer. This feature is available for all supported MCUs: MPC5674F (Mamba), MPC5668G(Fado) and MPC5643L (Leopard). System time also requires CPU_CLOCK field to be set on CPU_DATA, hence CPU_CLOCK value must be added in CPU_DATA configuration to have a system timer configured.<br />
This is an example to configure Decrementer as System Timer:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_DECREMENTER";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "DECREMENTER";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
<br />
Furthermore for MPC5643L (Leopard) is available a system timer based on Freescale STM (System Timer Module), that is a device available in several Freescale PowerPC MCUs. In this case the following configuration must be take into account:<br />
<br />
EE_OPT="EE_SYSTEM_TIMER_DEVICE_STM";<br />
...<br />
...<br />
CPU_DATA = PPCE200ZX {<br />
CPU_CLOCK = 120.0; // for a 120 Mhz cpu clock<br />
...<br />
...<br />
}<br />
...<br />
...<br />
COUNTER system_timer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM";<br />
SYSTEM_TIMER = TRUE;<br />
};<br />
SECONDSPERTICK = 0.001; // 1 msec tick duration<br />
CPU_ID = "default_cpu";<br />
};<br />
...<br />
...<br />
<br />
<br />
;EEOPTs<br />
: See also [[EEOPT]] for common EEOPTs.<br />
: Special options for the PPC e200 ERIKA porting can be specified through '''EE_OPT''' items in the '''OS''' section (please notice that the value for an '''EE_OPT''' is a string, so double quotes (") must be added around the values in this list.<br />
:; EE_SYSTEM_TIMER_DEVICE_DECREMENTER (see system timer section above)<br />
:; EE_SYSTEM_TIMER_DEVICE_STM (available only for MPC5643L, see system timer section above)<br />
:;EE_ISR_DYNAMIC_TABLE<br />
::Used to enable dynamic ISR table support that let register ISR handlers at runtime calling <code>EE_e200z7_register_ISR</code>.<br />
:;__E200ZX_EXECUTE_FROM_RAM__<br />
:: When specified, a linker script is used that maps both code and data in the RAM space. Executables produced with this option can be used only together with a debugger that loads the program in memory. By default, code and constant data are mapped to Flash, data to RAM.<br />
:;__CODEWARRIOR__<br />
:: Invoke Freescale CodeWarrior compiler. See [[#Freescale CodeWarrior]] for information on how to configure the compiler. The default compiler is Wind River Diab; see [[#Wind River Diab]] for configuration.<br />
:;__USE_CUSTOM_LINKER_SCRIPT__<br />
:: Don't use the dafault linker script. Users can direct the linker to use their own linker script by setting the <code>LDFLAGS</code> variable. Example:<br />
OS EE {<br />
EE_OPT = "__USE_CUSTOM_LINKER_SCRIPT__";<br />
LDFLAGS = "../my_linker_script.ld";<br />
};<br />
:;__USE_CUSTOM_CRT0__<br />
:: Don't use Erika default crt0. Users can provide their own crt0 by adding source files in the usual way (APP_SRC in the OIL file).<br />
;;__MINIMAL_CC_OPTIONS__<br />
:: Enable only the compiler flags absolutely needed to compile Erika, so users can easily add their preferences in CFLAGS.<br />
;;__EE_USE_MMU__<br />
:: Enable the MMU support. The MMU can be configured by calling <code>EE_e200zx_mmu_setup()</code>. See the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> for more details. An example configuration can be found in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt>.<br />
;;__EE_CRT0_INIT_MMU__<br />
:: Initialize the MMU from the crt0. See <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/demos/mmu_init/ examples/ppc/demos/mmu_init]</tt> for an example, and the MMU section in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt>.<br />
;;EE_NO_LIBEE<br />
:: To not generete the kernel library '''libee.a''' but link all the objects files (kernel + application) directly in an elf file. This option is useful to try Erika with CodeWarrior compiler with an evaluation license, because the archiver is not enabled with this license.<br />
;;DEBUG<br />
:: On this architecture, enabling debug symbols does not inhibit optimization.<br />
;;MPC5643L_STD_SW_MMU_CONFIG"<br />
:: This EE_OPT is valid only for MPC5643L (Leopard) and provides a standard (and in most cases sufficient) MMU configuration. This option is useful expecially running your code from FLASH where Debugger does not initializes the MMU for you.<br />
;;EE_LAUTERBACH_DEMO_SIM<br />
:: This option is available only for Mamba (MPC5674F), for details please take a look at DEMO_ErikaSim in the directory of templates. It causes the generation of Lauterbach scripts to use with Lauterbach simulator.<br />
<br />
There are a few examples in the ERIKA code base that can be used as a starting point for new projects. Examples include also a makefile, which can be used to compile a project without a need of an IDE. The makefile runs RT-Druid non-interactively, and requires the environment variable '''RTDRUID_ECLIPSE_HOME''' to point to the Eclipse directory where RT-Druid is installed.<br />
<br />
Examples can be accessed as templates in RT-Druid (see [[How to create, compile and debug an application for Freescale MPC5674F]]), or directly in the source code: [http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/ examples/ppc/].<br />
<br />
In the first version of ERIKA and RT-Druid supporting e200zX, the only e200-specific setting in the OIL configuration file was the CPU_DATA value, which had to be set to '''MPC5674F''' instead of '''PPCE200ZX'''. This not supported any more.<br />
<br />
=== APIs ===<br />
* List of functions (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_cpu.h?view=markup pkg/cpu/e200zx/inc/ee_cpu.h]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/cpu/e200zx/inc/ee_irq.h?view=markup pkg/cpu/e200zx/inc/ee_irq.h]</tt> for prototypes and other details):<br />
** EE_e200z7_register_ISR(level, handler, priority): Associate <tt>handler</tt> to the IRQ <tt>level</tt>, with the given <tt>priority</tt> (available only if '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' is set).<br />
** EE_e200z7_setup_decrementer(delay): Configure the decrementer to raise an interrupt every <tt>delay</tt> cycles.<br />
** EE_e200z7_setup_decrementer_oneshot(delay): Configure the decrementer to raise an interrupt <tt>delay</tt> cycles after invocation.<br />
** EE_e200z7_stop_decrementer(): Stop the decrementer from generating interrupts.<br />
** EE_e200zx_setup_fixed_intv(bitpos): Enable the fixed-interval interrupt.<br />
** EE_e200zx_stop_fixed_intv(): Disable the fixed-interval interrupt.<br />
** EE_e200zx_mmu_setup(entries, count): MMU initialization.<br />
<br />
Note: notice that the *_e200z7_* is slightly misleading since it seem to refer only to e200z7 family, it is a legacy name convention when the only supported architecture by Erika was Z7. Currently even Z0, Z4 and Z6 are supported hence these functions can be used for such architectures, although it refers to *_e200z7_*.<br />
<br />
====Interrupts====<br />
<br />
There are two way to configure ISR. The standard way is the static way with OIL configuration (example):<br />
<br />
ISR DecrIsr {<br />
CATEGORY = 2;<br />
ENTRY = "DECREMENTER";<br />
};<br />
<br />
ISR FixedIntvIsr {<br />
CATEGORY = 2;<br />
ENTRY = "FIXED_INTV";<br />
HANDLER = "fixed_intv_handler";<br />
};<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
ENTRY = "0";<br />
};<br />
ISR IsrMedium {<br />
CATEGORY = 2;<br />
PRIORITY = 2;<br />
ENTRY = "1";<br />
};<br />
<br />
ISR IsrHigh {<br />
CATEGORY = ;<br />
PRIORITY = 3;<br />
ENTRY = "2";<br />
HANDLER = "isr_high_handler";<br />
};<br />
<br />
In static ISR table handling mode there's full support for both ISR1 and ISR2 for '''external interrupt'''. To register an handler you should use the suitable macro ('''ISR1''' or '''ISR2''') passing the value of '''HANDLER''' field or the '''ISR name''', in case the former is missing. The configuration field '''ENTRY''' declare the position of the handler inside the vector table (the example show three handlers that get the first three positions in vector, corrisponding to the first three software interrupt request). Priority field corripsond to interrupt priority value set to corrisponding Interrupt Controller Priority select registers ('''INTC.PSR[(ENTRY)] = PRIORITY'''), the values have to be inside [0..15] range.<br />
<br />
There is direct support for two cpu '''internal exceptions''', those generated by the time base facilities: decrementer and fixed interval timer ('''ENTRY = "DECREMENTER"''' and '''ENTRY = "FIXED_INTV"'''' respectively.). Support for Watch-Dog timer will be added. To register an handler for internal interrupt you have to use '''ISR1_INT''' or '''ISR2_INT''' (two different couple of macros are needed to issue EOI, End Of Interrupt, only for external interrupts). Priority field in configuration have no meaning for internal interrupts.<br />
<br />
You can register handler by code dinamically with with the <code>EE_e200z7_register_ISR()</code> described above. To enable dynamic ISR table support you must declare '''EE_OPT=EE_ISR_DYNAMIC_TABLE''' configuration OIL file. The '''first 16 level''' of dynamic table are reserved for '''internal exceptions''' handlers, so you have to add this offset to the '''ENTRY''' value of the static approach to register an handler to the same interrupt source.<br />
<br />
ISRs (Interrupt Service Routines) are just void functions with no arguments. For external interrupts (IVOR4), the EOI (End Of Interrupt) is issued by ERIKA's handler; user ISRs need not bother about that.<br />
<br />
====Multicore support (MPC5668 and MPC5643L)====<br />
* Functions used for multicore support on MPC5668 (see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5668/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5668/inc/ee_dual.h]</tt> for prototypes and other details):<br />
** EE_mpc5668_start_z0(f): Enable the z0 CPU.<br />
<br />
The same paradigm of multicore support available for MPC5668G, is also available for the MPC5643L, (for details see <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/pkg/mcu/freescale_mpc5643l/inc/ee_dual.h?view=markup pkg/mcu/freescale_mpc5643l/inc/ee_dual.h]</tt>). Likewise MPC5668G, in order to start the slave core, a EE_mpc5643l_start_slave(f) call has to be provided at startup (typically in main function) immediately before the StartOS().<br />
<br />
=== Boards ===<br />
* ERIKA has been developed on an '''Axiom MPC5674evbfxmb evaluation board'''. This evaluation board has the MAMBA microcontroller (Freescale MPC5674F)<br />
** The kernel has no dependency on the board itself, but some of its functionalities can be used for debugging purposes. Including file "pkg/board/axiom_mpc5674fxmb/inc/ee_board.h" the following functions can be used:<br />
*** EE_leds_init(): which sets up the GPIOs associated with the leds.<br />
*** EE_EE_leds(mask): which turns the i-th led on or off depending on the state of the i-th bit in the mask passed as an argument.<br />
*** EE_led_<X>_on()/EE_led_<X>_off(): turns led X on or off.<br />
*** EE_buttons_disable_interrupts(button): disables the interrupt associated to the given button.<br />
*** EE_buttons_enable_interrupts(button): enables it.<br />
*** EE_buttons_clear_ISRflag(button): acknowledges the interrupt coming from the given button.<br />
*** EE_button_get_B<X>(): gets the status of button X.<br />
*** EE_buttons_init(): initializes the GPIOs associated to buttons.<br />
** The functions above are available if, respectively, __USE_LEDS__ and __USE_BUTTONS__ are defined upon inclusion of ee_board.h<br />
** The connections are assumed to be the following:<br />
*** GPIO 147-150: connected to LED0-3. Looking at the pins on the EVB:<br />
**** ETPUB1 -> USER_LED1<br />
**** ETPUB2 -> USER_LED2<br />
**** ETPUB3 -> USER_LED3<br />
*** GPIO 450: connected to BUTTON0 (ETPUC9 -> USER_DEV1)<br />
<br />
* Erika is available for the '''Freescale MPC5668EVB Evaluation Board'''. This evaluation board has the FADO microcontroller (Freescale MPC5668G)<br />
** for this board the are no available support for leds or buttons.<br />
<br />
* Erika is available for '''Freescale MPC564xLEVB Evaluation Board'''. This evaluation board has the LEOPARD microcontroller (Freescale MPC5643L)<br />
** for this board there is the same set of primitives defined for "Axiom MPC5674evbfxmb" board, hence a basic support for leds and button is available.<br />
<br />
== Multicore support ==<br />
<br />
In the ERIKA multicore support for PPC e200 there are a few aspects specific to the PPC e200 architecture, and they are described here. Please refer to [[ERIKA multicore support]] for general information on ERIKA multicore systems.<br />
<br />
The PPC evaluation board supported by Erika Multicore is the Freescale MPC5668G/E Evaluation kit, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5668GKIT. The multicore support is also provided for MPC5643L with the Freescale evaluation board MPC564xL EVB, the details can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=XKT564L.<br />
<br />
In multicore configuration, is it possible running both instances of the operating system both in RAM and Flash. For instance on MPC5668G, the internal SRAM is partitioned statically in two: memory from 0x40000000 to 0x4001FFFF is reserved to the first core and shared variables, while memory from 0x40020000 to 0x4003FFFF is reserved to the second core. 0x40020000 is used as the starting address of the second core. A similar approach is available for MPC5643L. In order to customize such memory assignments please refer to memory0.ld and memory1.ld files in "erika/pkg/mcu/freescale_mpc56XX/cfg/multicore" (where XX=43l for Leopard and XX=68 for Fado).<br />
<br />
Shared variable data is allocated in a single section (<tt>.mcglobald</tt>). Access to this section must be performed without cache, or the OS may malfunction. ERIKA crt0 does not enable cache; if you want to enable it, you should also make sure that the <tt>.mcglobald</tt> section is allocated on a page on its own by the linker script, and that the MMU is configured to mark such page as non-cached. <br />
<br />
The OS uses two software interrupts (6 and 7) and two hardware semaphores (0 and 1) of the MPC5668G to handle inter-core communication. They are initialised inside <code>StartOS()</code>. While all the other software interrupts and semaphores are available for user applications, those used by the OS should not be meddled with by user code. It is okay to briefly mask the interrupts with higher-priority interrupts or by disabling interrupts. In case of MPC5643L, as the microcontroller has two different interrupt controllers (one for each core), SW interrupt number 7 is used for both cores. Even if the MPC5643L has two SEMA4 modules, only the first module (the one associated to the master core) is used for this mechanism, this means that semaphores 0 and 1 of the first SEMA4 module are used for synchronisation (as in MPC5668G), while the remaining semaphores of the first SEMA4 module and all semaphores belonging to the second SEMA4 module are available for user applications.<br />
<br />
Examples of multicore applications are in <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/ examples/ppc/dual_examples]</tt>. In particular, <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/mono_activate01/ examples/ppc/dual_examples/mono_activate01]</tt> and <tt>[http://svn.tuxfamily.org/viewvc.cgi/erika_erikae/repos/ee/trunk/ee/examples/ppc/dual_examples/multi_event01/ examples/ppc/dual_examples/multi_event01]</tt> are complete applications, nearer to real-world usage.<br />
<br />
Erika multicore for PowerPC supports AUTOSAR OS-like functionalities. For details please see the following page (but take into account that these features have not been published yet):<br />
[[http://erika.tuxfamily.org/wiki/index.php?title=Erika_AUTOSAR_OS Erika AUTOSAR OS]]<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for PPC e200 produces a Lauterbach Trace32 configuration file (<tt>t32.cmm</tt>) and a ORTI description file (<tt>system.orti</tt>) inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger, please issue <code>t32mppc</code> from the output directory. The ERIKA build system honors the <tt>T32SYS</tt> environment variable, if set.<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named <tt>start.sh</tt>) is produced in the output directory. To run the debugger, please issue <code>start.sh</code> from the output directory. The script creates two instances of the debugger, one for each core. For instace when MPC5668G is turned on, only the first (Z6) core is enabled. In order to simulate the real setup, the debugger connected to the second (Z0) core does not enable its core, but it is responsibility of the code running on the Z6 core to enable the Z0 core (this is different from the example script for MPC5668G distributed with the Lauterbach Trace32 software). Nonetheless, the startup script loads all the code and the debug symbols for both core and both debugger instances. In a typical debugging session, you start the execution of the code on the Z6 core from its debugger, and then, when the Z0 core has become active, start also the code on the Z0 core from the Z0 debugger. The barrier inside <code>StartOS()</code> comes handy to synchronize the code running on the two cores. The <tt>start.sh</tt> script runs only on Linux; currently the ERIKA build system does not support Windows to run Trace32 for e200 multicore systems. A similar approach has been adopted for MPC5643L.<br />
<br />
==Internals==<br />
<br />
===Interrupts===<br />
<br />
Interrupt handling in PPC e200 ERIKA uses software vector mode and a single entry point for all interrupts and exceptions, which is <code>EE_e200z7_irq()</code>. This function calls the user ISR and issues the end-of-interrupt for external interrupts; when the served interrupt is not nested, i.e., it interrupted a task directly, <code>EE_e200z7_irq()</code> also calls the scheduler before returning.<br />
<br />
This scheme of IRQ handling can be changed by rewriting the crt0 and changing the IVOR setup. In this way it is possible, for example, to use hardware vector mode. Please note that it is important that the end-of-interrupt be issued before calling the scheduler, as the scheduler may not return when a new task is to be scheduled.<br />
<br />
== Download and install of Eclipse, RT-Druid, and ERIKA source ==<br />
<br />
To build an ERIKA application you need:<br />
* ERIKA source code<br />
* RT-Druid and a hosting Eclipse<br />
* Some command-line tools<br />
<br />
=== ERIKA source code ===<br />
<br />
ERIKA source code is bundled with RT-Druid. ERIKA for PPC e200 honors the definition of '''ERIKA_FILES''', so you can use the latest version of ERIKA as explained in [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application#Bleeding edge]].<br />
<br />
=== Eclipse and RT-Druid in one piece ===<br />
<br />
A complete version of an Eclipse installation together with the RT-Druid plugin can be downloaded from this page:<br />
http://erika.tuxfamily.org/erika-for-multiple-devices.html. Please make sure to use a version not older than 1.6.0 beta. See also [[Tutorial: Installing ERIKA and RT-Druid, and compile your first application]].<br />
<br />
=== Eclipse and RT-Druid piece by piece ===<br />
<br />
Alternatively, if you already have a copy of Eclipse or you want to use a version of Eclipse different from the one provided by the page above, you can follow this procedure.<br />
* To download the e200 plug-in for Eclipse refer the following site: [http://download.tuxfamily.org/erika/webdownload/rtdruid_beta Plug-in download site].<br />
Procedure for installation:<br />
* Step 0:<br />
: Get ''Eclipse'' and required plug-ins;<br />
: Where possible, the suggestion is to download the ''all in one update site'' and use the eclipse update manager or to use the eclipse update manager directly on a web site;<br />
:* Eclipse<br />
:: If you don't have any eclipse installations, you can download eclipse with cdt already installed from [http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/heliossr1 Eclipse IDE for C/C++].<br />
:: It is also possible use an already installed distribution of eclipse or to download one (for example from [http://www.eclipse.org/downloads Eclipse Downloads]) and then add all missing plug-ins.<br />
:* EMF<br />
:: The main page to download EMF is [http://www.eclipse.org/modeling/emf/downloads/?project=emf Eclipse Modeling Framework].<br />
:: The version to download is related to the eclipse version: eclipse 3.3 -> emf 2.3 , eclipse 3.4 -> emf 2.4, eclipse 3.5 -> emf 2.5, eclipse 3.6 -> emf 2.6. <br />
:: The list of required plugins is:<br />
::: org.eclipse.emf.common<br />
::: org.eclipse.emf.ecore<br />
::: org.eclipse.emf.edit<br />
::: org.eclipse.emf.common.ui<br />
::: org.eclipse.emf.edit.ui<br />
:: Clearly it is possible to install more plugins, like the whole emf runtime or sdk<br />
:* CDT<br />
:: The main page to download CDT is [http://www.eclipse.org/cdt/downloads.php CDT Downloads].<br />
:: Also here, the version to download is related to eclipse version. <br />
:: In this case is required only the cdt runtime plugin.<br />
: [http://erika.tuxfamily.org/forum/viewtopic.php?f=6&t=651&sid=89784e2d97765c3f1c41f6e3c049437a#p727 Forum Post (in italian) about installing the Eclipse plugins]<br />
* Step 1:<br />
: Open ''Eclipse'';<br />
: From the menu ''Help'' select ''Install New Software...'';<br />
: Add with the button ''Add...'' the reference site mentioned above (fill the Location field with this: http://download.tuxfamily.org/erika/webdownload/rtdruid_beta);<br />
: Tick all plug-ins related to RT-Druid core and to Erika Enterprise, then click on the button ''Next'' to install them;<br />
: Restart Eclipse;<br />
* Step 2:<br />
: From the menu ''File'' select ''New'' and then RT-Druid Oil and C/C++ Project;<br />
: From the Project menu select one of the available e200 demo tests;<br />
: Then click on the project name with the right mouse button and build to obtain the elf object module for debugging;<br />
<br />
=== Additional software ===<br />
<br />
ERIKA uses GNU make and some command-line utilities to build programs. You need the following tools (please notice that only the less common commands are listed here; very common commands that are present in any Unix/POSIX system like ''ls'' are not listed for simplicity):<br />
* make (GNU version)<br />
* gawk (GNU AWK)<br />
* sed<br />
* grep<br />
<br />
For Linux the above commands are present in virtually every standard installation; but you can always install them from the respective packages of your distributions.<br />
<br />
For Windows, [http://www.cygwin.com/ Cygwin] is recommended. Please make sure to include the above packages (package names are the same as the tool names).<br />
<br />
== HOWTOs ==<br />
* [[How to create, compile and debug an application for Freescale MPC5674F]]<br />
* [[How to run the MODISTARC regression tests for Freescale MPC5674F]]<br />
<br />
<br />
[[Category:Supported Devices]]</div>Francescohttps://erika.tuxfamily.org/wiki/index.php?title=Erika_AUTOSAR_OSErika AUTOSAR OS2014-07-14T10:42:03Z<p>Francesco: /* Multicore Autosar OS Support */</p>
<hr />
<div>= Multicore Autosar OS Support =<br />
<br />
ERIKA support multicore environments a way before than the first Autosar Multicore OS Release. So it happened that the historical [[ERIKA multicore support]] addresses some of the same requiremets of AUTOSAR Multicore OS with a completely different policy.<br />
<br />
In detail all the primitives calls on other core, with traditional implementation, called '''Remote Notifications''' or '''RN''', are done '''asynchronously''' with a fire and forget policy. This approach reduce latency to minimun, but, on the other hand, don't give the opportunity to check for errors in the call site.<br />
<br />
Autosar, that take into account a way more code consistency and reliability than efficiency, requires that all the primitives calls on others cores are '''synchronous''' giving the opportunity to caller code to correctly handle errors.<br />
<br />
To implements Autosar OS requirements a completly new multicore dispatcher have been implemented. This have been called<br />
'''ERIKA Autosar RPC''' (Remote Procedure Call).<br />
<br />
Both traditional and the new dispatcher are available for Infineon AURIX and Freescale PowerPC (MPC5777C). You can switch between them in OIL with the REMOTENOTIFICATION oil field.<br />
<br />
REMOTENOTIFICATION = USE_RN;<br />
<br />
Enable traditional '''Remote Notification''' dispatcher. It's the default value, so you don't need to write this.<br />
<br />
REMOTENOTIFICATION = USE_RPC;<br />
<br />
Enable the new '''AUTOSAR Remote Procedure Call''' dispatcher.<br />
<br />
Currently with the new RPC dispatcher you can execute on remote cores all the following primitives:<br />
<br />
* ActivateTask<br />
* ChainTask (Terminate local TASK but can schedule on remote core)<br />
* GetTaskState<br />
* SetEvent<br />
* GetAlarmBase<br />
* GetAlarm<br />
* SetRelAlarm<br />
* SetAbsAlarm<br />
* CancelAlarm<br />
* GetCounterValue<br />
* GetElapsedValue<br />
* ShutdownOS ( with new ShutdownAllCores API )<br />
<br />
So in addition to TASK and EVENT primitives, the new muticore dispatcher support Counters and Alarms as required by Autosar specifications. Multicore awareness have been added to ShutdownOS to fulfill multicore AUTOSAR shutdown sequence. <br />
<br />
=== New Multicore API ===<br />
<br />
AUTOSAR expect a master/slaves multicore enviroment that naturally fit AURIX architecture.<br />
New API to start and stops slave cores specified in AUTOSAR v4.0 rev 3.0 have been added:<br />
<br />
*'''StartCore''': This function starts the core specified by the parameter CoreID. The OUT parameter allows the caller to check whether the operation was successful or not. If a core is started by means of this function '''StartOS''' shall be called on the core. It is not supported to call this function after '''StartOS()'''.<br />
*'''StartNonAutosarCore''': The function starts the core specified by the parameter CoreID. It '''is allowed''' to call this function after '''StartOS()'''. The OUT parameter allows the caller to check whether the operation was successful or not. It is '''not allowed to call StartOS''' on cores activated by '''StartNonAutosarCore'''.<br />
*'''GetNumberOfActivatedCores''': returns the number of cores activated by the StartCore function. This function might be a macro<br />
*'''GetCoreID''': The function returns a unique core identifier.<br />
*'''ShutdownAllCores''' : After this service the OS on all AUTOSAR cores is shut down. Allowed at TASK level and ISR level and also internally by the OS. The function will never return. The function will force other cores into a shutdown.<br />
<br />
=== New Spinlocks API ===<br />
<br />
Support for AUTOSAR Spinlock API have been added. OIL implementation have been extended to support Spinlocks configuration.<br />
<br />
There's two spinlocks behaviour modes: '''SINGLE''' and '''ORDERED'''. If '''SINGLE''' mode is configured a core get an error if, holding a spinlock, try to get access to another one. If '''ORDERED''' mode is configurated the core get this error only if it try to get spinlocks out of the order (see AUTOSAR documentation paragraph 7.9.29 The spinlock mechanism).<br />
<br />
To configure spinlocks in '''SINGLE''' mode, just don't provide any order:<br />
<br />
SPINLOCK spinlock_1 { };<br />
SPINLOCK spinlock_2 { };<br />
SPINLOCK spinlock_3 { };<br />
<br />
To configure spinlocks in '''ORDERED''' mode provide a '''complete ordering''':<br />
<br />
SPINLOCK spinlock_1 { NEXT_SPINLOCK=spinlock_2; };<br />
SPINLOCK spinlock_2 { NEXT_SPINLOCK=spinlock_3; };<br />
SPINLOCK spinlock_3 { };<br />
<br />
<br />
Provided AUTOSAR API to interact with Spinlocks are:<br />
<br />
*'''GetSpinlock ''': Tries to occupy a spin-lock variable. If the function returns, either the lock is successfully taken or an error has occurred. The spinlock mechanism is an active polling mechanism. The function does not cause a de-scheduling.<br />
*'''ReleaseSpinlock''': Releases a spinlock variable that was occupied before. Before terminating a TASK all spinlock variables that have been occupied with GetSpinlock() shall be released. Before calling WaitEVENT all Spinlocks shall be released.<br />
*'''TryToGetSpinlock''': Has the same functionality as GetSpinlock with the difference that if the spinlock is already occupied by a TASK on a different core the function sets the OUT parameter to TRYTOGETSPINLOCK_NOSUCCESS and returns with E_OK.<br />
<br />
Two spinlocks implementation are provided. The '''trivial''' one that does not guarentee upper bond wait, but that can implement the try-to-get behaviour. And the '''queued''' one that prevent from starvation queuing requests, but cannot implement try-to-get behaviour (TryToGetSpinlock API is mapped into GetSpinlock).<br />
<br />
To enable '''queued spinlocks''' just add to the OIL:<br />
<br />
SPINLOCKS = QUEUED;<br />
<br />
IMPORTANT: QUEUED spinlocks are not available for Erika on PowerPC.</div>Francesco