- 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
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- Advanced AnalogAdvanced Analog
- Neural Processing UnitsNeural Processing Units
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- 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
- S32M
- S32Z/E
-
- 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
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- Generative AI & LLMs
-
- 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
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
- RFID / NFC
- Advanced Analog
- Neural Processing Units
-
- NXP Tech Blogs
- Home
- :
- Translated Content
- :
- Multi Source Translation Content
- :
- 2395839_en-US
2395839_en-US
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2395839_en-US
2395839_en-US
I have found three problems with the BCTU module in the RTD code version S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206. The detailed issues are listed below:
Issue 1: In file Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c, line 1558, the current code uses bitwise OR assignment: BctuBasePtr->FIFOERR |= FifoWatermarkMask; It should be modified to direct assignment: BctuBasePtr->FIFOERR = FifoWatermarkMask;
Issue 2: In file Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c, lines 567 and 568, the existing code contains incorrect bit shift operations. The original code is shown below:
ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << (Index * 2u))) != 0U) ? (BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << Index) : 0U;
ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << (Index * 2u))) != 0U) ? (BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << Index) : 0U;
These two lines should be revised to the correct shift logic as follows:
ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << Index)) != 0U) ? (BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << (Index * 2u)) : 0U;
ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << Index)) != 0U) ? (BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << (Index * 2u)) : 0U;
Issue 3: There is a type inconsistency alignment issue between the MCAL/SDK code generation tools and the static source code of the BCTU module. In the MCAL generated code (Adc_TS_T40D34M70I1R0/generate_PB/Adc_RegOperations.m, line 2397), the arrays defined in both header and C files uniformly adopt the uint32 type. In the SDK generated code, the type definition is inconsistent between header and C files: the array type in eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.h (line 249) switches between uint16 and uint32 depending on whether the BctuFifoDmaRawData option is enabled, while the corresponding array in eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.c (line 317) is fixed as uint32 type. In the static code (Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c, line 1629), the transmission length (2-byte or 4-byte) is determined dynamically based on the BctuFifoDmaRawData configuration. All the following abnormal problems occur when theBctuFifoDmaRawData option is unchecked:
1. For SDK projects: The mismatched array types between header and C files cause direct compilation failures.
2. For MCAL projects: Although compilation can succeed, the fixed uint32 array definition leads to half of the memory space being wasted. Besides, each uint32 data unit contains two ADC results, requiring manual splitting of high and low uint16 values during data parsing.
The above three bugs exist in the official version S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206. We hope NXP software engineers can fix these BCTU module defects in the next RTD release.
Hi@chenwilsoft
Your question has been escalated to the internal forum and is awaiting confirmation from the design team.
No ratings