- NXP Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- Wireless Connectivity
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- Vigiles
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
-
1. I am using AN4907 and AN4908 based etpu library for engine management control using MPC5634M ECU. I am able to get crank sync and obtain all pulses: spark, fuel as per requirement. However, when logging CRANK ERRORS, i am getting some undesired signal values (108,-116 etc) which are not present in API document.(please see attached image and log file).
Can you please help me on this regard.
2. i have been using AN4907 ver 1. i see now there is a rev2. could you link me to corresponding AN4908SW file with the changes in API, i am unable to find it online.
Thank,
Arjun.
已解决！ 转到解答。
Hello Arjun,
The crank error flags are accumulated (bitwise-ORed) in the crank eTPU software and then cleared every time the fs_etpu_crank_get_states() API is called. Thus the two values you mentioned work out to several accumulated errors: 108 => 64 (TIMEOUT_AFTER_GAP) + 32 (TIMEOUT_BEFORE_GAP) + 8 (STALL) + 4 (TIMEOUT) and -116 => 140 (unsigned int8) => 128 (TOOTH_IN_GAP) + 8 (STALL) + 4 (TIMEOUT).
I have not looked at your crank signal data nor tried to simulate it, but I would assume it is such that it results in a cascade of errors that net error values of 108 and 140.
Hello Arjun,
The crank error flags are accumulated (bitwise-ORed) in the crank eTPU software and then cleared every time the fs_etpu_crank_get_states() API is called. Thus the two values you mentioned work out to several accumulated errors: 108 => 64 (TIMEOUT_AFTER_GAP) + 32 (TIMEOUT_BEFORE_GAP) + 8 (STALL) + 4 (TIMEOUT) and -116 => 140 (unsigned int8) => 128 (TOOTH_IN_GAP) + 8 (STALL) + 4 (TIMEOUT).
I have not looked at your crank signal data nor tried to simulate it, but I would assume it is such that it results in a cascade of errors that net error values of 108 and 140.
Hello John,
Thanks a lot for the answer. it makes perfect sense.
Could you also suggest at what rate fs_etpu_crank_get_states() function needs to be called? is the crank ISR at every engine cycle sufficient?
Thanks,
Arjun.
For most of the data retrieved by fs_etpu_crank_get_states() once per cycle is probably sufficient (and note that the ISR also fires on stall detection or during syncing when the host needs to evaluate cam data for full sync). But for (instantaneous) speed and perhaps other parameters, polling at a higher rate (10ms or faster) may make sense depending upon your application. A new interface that only retrieves the necessary data for these needs may be better than re-using fs_etpu_crank_get_states().
