Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
RTD update issue - MBDT In the S32 Design Studio version 3.6.1, wanted to update the RTD version 7.0.0 but i could only update it to 5.0.0, its showing error when i try updating RTD version 6.0.0 and further.  Screenshot 2026-08-06 143602.png Eclipse IDE Usage and Settings SDKs Re: RTD update issue - MBDT Screenshot 2026-08-07 101727.png i have installed the IDE 3.6.10 version, and tried to download the rtd version 7.0.1 but i couldnt, system network is connected properly, and it shows network issues only with this version and when i was working with the previous version 3.6.0 i didnt face any network issues. whenever i am opening the S32 IDE application the message box attached, pops up. If this is the case with changing network preferences, can you tell wat are the things to enable and disable in the settings? Screenshot 2026-08-07 095218.png Screenshot 2026-08-07 102413.png and the RTD gets installed, and when i am trying to check with example project (DIO S32k344) it shows the above error as attached,  in creating a new project i could not find any SDK options.  Screenshot 2026-08-07 102457.png Re: RTD update issue - MBDT Hi @Rathidevi  First, we recommend updating your S32DS installation to version 3.6.10. There is no need to install it as a separate instance, as it can be installed as an update to your existing S32DS installation. Detailed instructions are available in the S32 Design Studio 3.6.10 RFP Installation Guide, which can be found on the same download page as the S32DS installer. This update is recommended because RTD 7.0.1 was developed and validated using S32DS 3.6.4. To ensure compatibility and proper functionality, the IDE version should be the same as or newer than the version used for validation. Additionally, this requirement is noted in the Missing Requirements of the shared image. Regarding the RTD 7.0.1 installation, we recommend first uninstalling the currently installed RTD version and then installing RTD 7.0.1. This helps avoid potential conflicts between different RTD versions. BR, VaneB Re: RTD update issue - MBDT Hi @Rathidevi  It seems that the toolchain required by the RTD is missing from your installation. Please install NXP GCC for Arm Release version 10.2 build 1728. This should fix the problems with the examples and should also make RTD 7.0.1 available as an SDK option when creating a new project, as long as GCC 10.2 is selected as the project's toolchain.
記事全体を表示
CodeWarror Does anyone know where I can download a copy of CodeWarrior for 8-bit processors that will run under Linux (Ubuntu)? A general enquiry showed that C/W does run under linux, but all of the links are for windows. Re: CodeWarror Hello, Sorry for the inconveniences, the available version of CodeWarrior for 8-bit processors [CodeWarrior v11.1] is not available for Linux only windows. Best Regards, Luis Re: CodeWarror I know that! I have been using CW for "many years", running under Windows 7 which is running under Dropbox which is running under OSX on my Intel-based MAC. All I want is to do the same thing on my new ARM-based MAC. So far I have installed Dropbox and loaded Windows 11. (earlier versions of Windows are not compatible with the new MACs). I have installed CW 11.1 in Windows and it works. As I said in my original post CW does not recognise the Multilik debug probe because there is no device driver installed. Please refer to my original post for details of what is required 
記事全体を表示
Reinstalling the S32DS environment and SDK package has caused previous projects to fail to compile Reinstalling the S32DS environment and SDK package has caused previous projects to fail to compile. In the past, my project used S32DS V2.2 and SDK RTM 2.0.0. Now, after reinstallation, I am using S32DS.ARM.2018.R1 and have also installed SDK RTM 2.0.0. But now I can't compile the project. It seems that it can't recognize the project itself. You can see the details in the picture. Re: Reinstalling the S32DS environment and SDK package has caused previous projects to fail to compi Hi @yangcao1234  Please note that S32K1 SDK RTM 2.0.0 was released specifically for S32DS for ARM 2018.R1 Update 6. It was not intended to be used with S32DS for ARM 2.2, and compatibility with that version is not guaranteed. BR, VaneB
記事全体を表示
SL3S1206FUD2/HA Request for Good Die identification documentation / Wafer Map Dear Supplier, We would like to confirm whether you have provided any documentation or markings that distinguish “Good Die” from “NG Die” on the wafer. Specifically, we are looking for: A wafer map (indicating which die passed/failed testing), A test result report, or Physical markings on the wafer surface (e.g., ink dots, laser marks) that clearly identify usable die. After inspecting the wafer under our microscope, we could not find any visible physical markings. This raises concerns that we may not be able to reliably differentiate good die from defective die. Could you please help check whether such information was included with the shipment, or assist us in obtaining these materials from the manufacturer? We need this data for our subsequent processing steps. Thank you for your kind assistance. We look forward to your reply.
記事全体を表示
Concern about Guiguider License Compliance Dear NXP Semiconductors, I am writing to report a potential violation of the license agreement for your Guider software. As we understand, the license for your Guider software explicitly prohibits its commercial use in the development of products based on non-NXP series chips. However, a major multinational corporation is currently using this software in the development of commercial products based on Rockchip series main control chips, which appears to be a clear breach of your license terms. I would like to ask: Does NXP plan to take any enforcement actions to protect its intellectual property rights in this matter? Additionally, if I were to file a formal complaint regarding this violation, what specific evidence would you require to initiate an investigation? I look forward to your response. 回复: Concern about Guiguider License Compliance Guiguider is being used in violation of its license. Your company's Guider software license explicitly prohibits its use in commercial development of non-NXP series chips. A large multinational corporation has violated this license by applying the software to commercial products using Rockchip's main control chips. Will your company take legal action? If I wish to file a complaint, what evidence should I provide? Re: Concern about Guiguider License Compliance Thank you for raising this concern. GUI Guider is provided subject to license terms that govern its permitted use, including limitations regarding supported hardware platforms. NXP expects users of its software tools to comply with the applicable license terms.  We are not aware of the specific circumstances referenced in your post and therefore cannot comment on any particular company, product, or alleged activity. If you have specific information regarding potential misuse of GUI Guider, please provide additional details through the appropriate direct NXP channels (rather than via community postings) so that the information can be reviewed. Examples of helpful information may include the identity of the organization involved, details regarding the product or project, or other supporting information. We appreciate your interest in NXP products and software tools.
記事全体を表示
Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hello NXP Support Team, We are evaluating object detection on the FRDM i.MX95 platform using the Neutron SDK v3.1.3 and are unable to generate an NPU-compatible model. The Neutron converter successfully loads the model, but reports that 0 operators are mapped to the Neutron NPU. Environment Target Board: FRDM i.MX95 Neutron SDK: 3.1.3 Ultralytics: Tested with both YOLO11 and YOLOv8 eIQ Toolkit: Used for ONNX → TFLite conversion Model: Custom single-class peg detector Training Command $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=models \ name=peg_detector_v8 Export Command $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml We also tested an alternative workflow: Export PyTorch → ONNX Convert ONNX → INT8 TFLite using the NXP eIQ Toolkit Both workflows produced the same result when compiled with the Neutron SDK.   Neutron Compilation ~/Downloads/eiq-neutron-sdk-linux-3.1.3/bin/neutron-converter \ --target imx95 \ --input best_int8.tflite \ --output my_model_int8_npu.tflite   Converter Output The converter reports: Operators after import: 341 Operators after optimization: 367 Operators converted: 0 Operator conversion ratio: 0 / 367 Number of Neutron graphs: 0 Warnings: WARNING: None of the operators from the graph was mapped to Neutron. WARNING: The converted model is the same as the input model because no operators were mapped to Neutron. WARNING: Graph has FLOAT operators which are NOT supported! This can result in low conversion ratio. Additional Information We observed the same behavior with: YOLO11 YOLOv8 Direct Ultralytics TFLite export ONNX → eIQ Toolkit → INT8 TFLite All generated TFLite models result in 0 operators being mapped by the Neutron compiler. Questions Are YOLOv8 or YOLO11 object detection models officially supported by the Neutron compiler for the i.MX95? Is there a recommended export pipeline for YOLO models targeting the i.MX95 NPU? Are there any known limitations with the current Neutron SDK (v3.1.3) regarding YOLO detection heads? Does NXP provide a reference YOLOv8/YOLO11 model that successfully compiles for the i.MX95 NPU? Is there any additional compiler option or preprocessing step required to enable operator mapping? We would appreciate any guidance, recommended workflows, or reference models that are known to work with the i.MX95 Neutron NPU. Thank you. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Thank you for your response. I would like to inquire if there is a standard procedure available for training, exporting, and deploying models on the IMX95 board. As we currently have the ARA2, we are looking to fully utilize its capabilities and customize our models. We have upcoming demos for NXP Tech Days, and your assistance in this matter would be greatly appreciated. Thank you for your help. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Tried the yolo8m model from eIQ model zoo on imx95 board with LF 2026 Q2 release image. kernel version is 6.18.20 using neutron SDK 3.1.2. it works. xing_lei_0-1783672312304 (1).png     You can try it firstly by: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model --graph=yolov8n-det-int8-smart.imx95.tflite --external_delegate_path=/usr/lib/libneutron_delegate.so more info you can refer the README eiq-model-zoo/tasks/vision/object-detection/yolov8 at main · NXP/eiq-model-zoo What's more, you can attached model and details log of convert/complier. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Based on the converter log, the first issue to resolve is that the generated TFLite model still contains FLOAT operators:   WARNING: Graph has FLOAT operators which are NOT supported! For i.MX95 Neutron, the input to neutron-converter must be a TFLite model whose operators and quantization format are compatible with the Neutron compiler. In particular, the i.MX95 Neutron flow expects quantized TFLite and symmetric int8 weights. If the model still contains FLOAT operators/tensors after the Ultralytics export or ONNX-to-TFLite conversion, the converter may be unable to create any Neutron-compatible subgraph, which is consistent with the reported result:   Operators converted: 0   Number of Neutron graphs: 0 YOLOv8 has been evaluated on i.MX95 in some flows, but full end-to-end YOLOv8/YOLO11 offload should not be assumed for arbitrary Ultralytics exports. Depending on the exported TFLite graph, only part of the model may be converted to NeutronGraph and unsupported operators will remain on CPU. Therefore, the recommended next step is to inspect/profile the generated TFLite model and confirm: the graph is fully quantized, there are no FLOAT operators, weights are symmetric int8, input/output tensor types are compatible, or converted with the Neutron converter uint8-to-int8 options if applicable, YOLO post-processing such as decode/NMS is kept outside the NPU graph unless the exact operators are confirmed supported by the SDK. Please also ensure that the neutron-converter version and the Neutron runtime/firmware/delegate on the board are from the same compatible SDK/BSP release. As a recommended flow, please try the NXP/eIQ conversion path:   PyTorch -> ONNX with static input shape -> NXP/eIQ quantization with representative calibration data -> quantized TFLite -> neutron-converter --target imx95 If the model has uint8 input/output tensors, please also test:   --convert-inputs-uint8-to-int8   --convert-outputs-uint8-to-int8 If the conversion still reports 0 mapped operators after removing FLOAT operators, please share:   - the complete neutron-converter log with verbose/profiling output if available,   - the TFLite operator list,   - tensor data types and quantization parameters,   - the exact BSP/runtime Neutron delegate/firmware versions on the FRDM i.MX95 board,   - whether the YOLO detection head includes NMS or other post-processing inside the TFLite graph. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hi  i am running ubuntu 24.04, but eiq_toolkit is avaialble for only 20.04.03.  how can i use eiqToolkit and Quantization Using eIQ Toolkit Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Recommended End-to-End Workflow Model Training (PC) Train using your preferred framework: Ultralytics YOLOv8 PyTorch TensorFlow ONNX-native workflows For object detection, NXP already provides YOLO reference recipes in the eIQ Model Zoo, including YOLOv8 object detection models. [github.com], [github.com] Example: Shell yolo detect train \ model=yolov8n.pt \ data=dataset.yaml \ imgsz=640 \ epochs=100 ` Export to ONNX NXP generally recommends using ONNX as the interchange format before quantization and deployment. yolo export \ model=best.pt \ format=onnx The Neutron enablement presentations explicitly describe a flow based on: Plain Text PyTorch ↓ ONNX ↓ Quantization ↓ TFLite ↓ Neutron Converter rather than directly targeting deployment from training artifacts. Quantization Using eIQ Toolkit The Neutron workflow documentation recommends using the eIQ Toolkit quantization utilities: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c input:: `` followed by: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite Show more lines This flow is explicitly documented in the i.MX95 Neutron enablement material. Compile for i.MX95 Neutron NPU neutron-converter \ --target imx95 \ --input model_int8.tflite \ --output model_neutron.tflite The Neutron converter creates Neutron-specific graph partitions that can be offloaded to the NPU. Validate Conversion Ratio A successful NPU deployment should report something similar to: Number of operators converted > 0 Number of Neutron graphs > 0 If you see: Operators converted: 0 Number of Neutron graphs: 0 then the model is not being accelerated by the NPU. Your current issue falls into this category. Deploy on FRDM-i.MX95 Run using TensorFlow Lite with the Neutron delegate: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` or ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so The i.MX Machine Learning User Guide identifies the Neutron Delegate as the acceleration mechanism for i.MX95 TensorFlow Lite models. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU In my test I did not train or export the model myself. I used a pre-generated YOLOv8 model from the eIQ Model Zoo and verified that it runs on the i.MX95 platform. The only command I actually used was: ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` with the model: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite For custom models, the recommended NXP flow is: PyTorch ↓ ONNX (static input shape) ↓ eIQ Toolkit ONNX2Quant ↓ eIQ Toolkit ONNX2TFLite ↓ Quantized TFLite ↓ neutron-converter --target imx95 Since your model reports: Plain Text Operators converted: 0 Number of Neutron graphs: 0 WARNING: Graph has FLOAT operators which are NOT supported! I suspect your generated TFLite graph is structurally different from the eIQ Model Zoo reference model. The first thing I would recommend is comparing the two models for: Input/output tensor type (INT8 vs UINT8) Presence of FLOAT operators Decode/NMS layers inside the graph Operator list reported by Netron / TFLite analyzer Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Can you please tell me how did you convert yolov8m_full_integer_quant.tflite to be able to run on the imx95 NPU?  Step followed and environment setup data(HOST).. would greatly help us. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Since eIQ Toolkit was validated on Ubuntu 20.04, the safest approach is: Docker Run a Ubuntu 20.04 container on your Ubuntu 24.04 host: docker run -it --name eiq \ ubuntu:20.04 /bin/bash Then install the required dependencies and eIQ Toolkit inside the container. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Unable to preserve confidence output when converting custom YOLOv8 ONNX model using eIQ Toolkit (onnx2quant) Overview Hi NXP Team, I'm trying to deploy a custom YOLOv8 single-class object detection model on the FRDM i.MX95 using the eIQ Toolkit. The complete conversion pipeline runs successfully, but after onnx2quant, the confidence output becomes all zeros while the bounding box outputs remain valid. Environment - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX Runtime 1.21.1 - TensorFlow 2.21 - neutron-converter 3.1.3 - Target: FRDM i.MX95 (tflite_runtime 2.19 + Neutron delegate) Conversion Pipeline 1. Train yolo detect train model=yolov8n.pt data=dataset.yaml imgsz=640 epochs=50 2. Export ONNX yolo export model=best.pt format=onnx opset=13 3. Verify ONNX Input : (1,3,640,640) Output: (1,5,8400) ONNX Runtime inference: Confidence Channel Max = 0.773 4. Generate calibration dataset Shape : (1,3,640,640) dtype : float32 Range : 0.0 - 1.0 5. Quantize onnx2quant best.onnx -c "images;calibration/images" -o best_quant.onnx Also tested: onnx2quant best.onnx -u Both produce the same result. 6. Verify Quantized ONNX Output : (1,5,8400) Bounding box channels remain valid. Confidence: Min = 0 Max = 0 Mean = 0 Decoded detections = 0 7. Convert to TFLite onnx2tflite best_quant.onnx -o best.tflite 8. Compile for Neutron neutron-converter --target imx95 --input best.tflite --output best_neutron.tflite Compilation succeeds. Operator conversion: 278 / 325 (85.5%) Investigation Performed Verified: • PyTorch model works • ONNX export works • ONNX Runtime inference works • Calibration dataset is correct • Real and random calibration produce identical results • TFLite reproduces the Quantized ONNX output • Neutron reproduces the TFLite output The issue first appears after: ONNX ↓ onnx2quant ↓ Quantized ONNX (confidence becomes zero) Additional Observation NXP reference model: Input : (1,640,640,3) INT8 Output: (1,84,8400) INT8 My converted model: Input : (1,3,640,640) FLOAT32 Output: (1,5,8400) FLOAT32 Is there a recommended export or quantization workflow for custom YOLOv8 models that preserves the confidence output? Could this be a limitation or bug in onnx2quant for models with a (1,5,8400) output? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Discussing with the AE team. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Has end-to-end been evaluated for the Ara240? The datasheet mentions two vector cores that can execute post-processing ops such as sigmoid and NMS. Could the compiler map NMS ops to the vector cores? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Sorry for the delay. I am trying to reproduce the conversion workflow.  One question for now, why the converted model's data type is FLOAT32? Have you tried to convert to INT8? The Neutron NPU requires the INT8 type as input data. I met the similar error on other models conversion and the root cause is the data type. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU The confidence output is lost due to a fundamental limitation of full INT8 quantization ( inference_output_type=tf.int8 ) applied to YOLOv8's output tensor. YOLOv8 packs bounding box coordinates and confidence scores into a single output tensor of shape  (1, 5, 8400) . The bbox values have a large dynamic range (~640 pixels), while the confidence scores are in the range of ~0 to 1. When the entire output tensor shares a single quantization scale, that scale is dominated by the large bbox values (~640), leaving only a fraction of one integer level to represent the entire confidence range (~1). As a result, all confidence values are effectively rounded to zero after INT8 quantization. Recommended Solution Instead of going through  onnx2quant , export INT8 TFLite directly from your trained  .pt  model using Ultralytics, then feed it into  neutron-converter : # Export INT8 TFLite directly (calibration uses your training dataset) yolo export model=best.pt \ format=litert \ imgsz=640 \ quantize=8 \ data=dataset.yaml \ fraction=0.1 # Compile for Neutron (unchanged) neutron-converter --target imx95 --input best_int8.tflite --output best_neutron.tflite For the input and output data type, please ensure they are np.int8: interp = tf.lite.Interpreter(model_path=TFLITE_INT8) interp.allocate_tensors() inp_d  = interp.get_input_details()[0] out_ds = interp.get_output_details() inp_scale, inp_zp = inp_d["quantization"] out_d = out_ds[0] out_scale, out_zp = out_d["quantization"] print(f"  Input  dtype={inp_d['dtype']}  shape={inp_d['shape'].tolist()}"       f"  quant=(scale={inp_scale:.6f}, zp={inp_zp})") print(f"  Output dtype={out_d['dtype']}  shape={out_d['shape'].tolist()}"       f"  quant=(scale={out_scale:.6f}, zp={out_zp})")# Determine input format from shape in_shape = inp_d["shape"].tolist()   # [1,3,640,640] or [1,640,640,3] if in_shape[1] == 3:     # NCHW     src=img_nchw else:     # NHWC     src=img_nhwcif inp_d["dtype"] == np.int8:     src_int8 = np.clip(np.round(src / inp_scale + inp_zp), -128, 127).astype(np.int8)     interp.set_tensor(inp_d["index"], src_int8) else:     interp.set_tensor(inp_d["index"], src.astype(np.float32))interp.invoke() raw_out = interp.get_tensor(out_d["index"])  # may be int8 or float32if out_d["dtype"] == np.int8:     dq_out = (raw_out.astype(np.float32) - out_zp) * out_scale else:     dq_out = raw_out.astype(np.float32)dq_out = dq_out[0]   # (5, 8400) normalized# Rescale bbox back to pixel coords for display BBOX_SCALE = 640.0 tfl_bbox = dq_out[:4] * BBOX_SCALE   # (4, 8400) tfl_conf = dq_out[4]                  # (8400,) Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hi Tried the commands you shared... But neutron-converter is failing to convert the model... please find the log attached for your reference Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Please provide the log. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hi, Please find the attached log files. I was able to successfully train the model and run it on the i.MX95 NPU. However, I noticed one observation regarding the quantization parameters: Quant: (0.003921568859368563, -128) The negative quantization zero-point value caught my attention, and I would like to confirm whether this is expected behavior. Please find the attached logs for your reference. Thank you.
記事全体を表示
GPIO Based on the S32K324 MCU, how to configure a GPIO to high‑impedance state using S32DS. Re: GPIO Hi Please refer to previous similar discussions: S32K3 GPIO HIGH-Z If the pin may have previously enabled internal pull, in order to satisfy the tristate definition in S32K3XXRM, Siul2_Port_Ip_SetPullSel(..., PORT_INTERNAL_PULL_NOT_ENABLED) should be called to ensure PUE=0; Best Regards, Robin
記事全体を表示
Query Regarding PCA9450CHN Voltage Configuration Through I2C We are using the PCA9450CHN PMIC and understand that it powers up with default regulator voltages, which can be modified through I2C programming. Could you please explain the complete sequence for changing these voltages after power-on, including when the SoC starts communicating with the PMIC? Also, please let us know the recommended debugger or tools to monitor and verify the PMIC register programming and voltage changes. Board Design HW-Open-Source Re: Query Regarding PCA9450CHN Voltage Configuration Through I2C guoweisun_0-1786078934821.png You can refer to above after the POR_B signal pull high and the PCA9450C enter into RUN mode you can change its power rails output value.
記事全体を表示
S32K566 LPUART Communication Issue Hi, I am using the Uart_Example_S32K566_M7 module on the S32K566 microcontroller with an LPUART module clock of 50 MHz. I configured the baud rate to 115200 and am sending 0xAA data to the PC using a UART-to-USB converter. However, the received data is incorrect (0x00 0x80 0x80). When I configure the baud rate to 115200/8 = 14400, the data is received correctly. I also tried different baud rates such as 9600 and 19200. I am using S32DS 3.6.6 and SDK 0.8.0. Uart_Example_S32K566_M7 source code also attached here please find.  I have attached the configuration and received data screenshots for reference. Manikandan_Aruchamy_0-1786092514163.png Receiver terminal window baud rate is 115200: Manikandan_Aruchamy_1-1786092584169.png Receiver terminal window baud rate is 14400: Manikandan_Aruchamy_2-1786092633034.png Re: S32K566 LPUART Communication Issue Hello @Manikandan_Aruchamy , I hope this email finds you well. I am writing to you in regard to a product currently in your possession – an NPI (New Product Introduction) which has not been officially launched yet. Please be advised that customers who have been granted early access to such products have assigned their field engineers. Your designated field engineer should serve as your primary support channel for any issues, concerns or queries you may have about this product. Our online support team will be opening a wider range of support for this product once it has been officially released. Until then, we will not be equipped to provide the desired assistance. Thank you for your understanding. Best regards, Pavel
記事全体を表示
The SPI duty cycle of S32K322 is not 50% for 8MHz Dear NXP team,           We are working on an improvement activity where we need to have the 8MHz SPI SCLK to be periodic within SPI transactions. We measured the SPI SCLK for 8MHz (which is driven by the SPI peripheral driver in S32K322) and found that 50% duty is not maintained. When we lower the frequency to 1/2/4 MHz we see 50% duty being maintained for those SCLK frequencies.  Question - Is this any Hardware limitation of the Peripheral driver or by changing the driver settings, desired 50% duty can be obtained for 8MHz? PFA the screenshots where duty is maintained for 1MHz and not for 8MHz Note: We have connected Logic Analyzer from Saleae that has higher sampling resolution (250MS/s) to measure the SPI signals Re: The SPI duty cycle of S32K322 is not 50% for 8MHz Hi, the LPSPI clock duty cycle is determined by the SCKSET and SCKHLD timing parameters. A 50/50 duty cycle is only obtained when these fields are programmed to equal values. Depending on the selected LPSPI functional clock and the divider values required to generate 8 MHz, an exact 50/50 duty cycle may not be achievable due to the timing resolution of the clock generator. The observed 76 ns / 48 ns high-low times appear consistent with such divider quantization effects. PetrS_0-1786090730852.png So, try to calculate the expected duty cycle from your LPSPI functional clock frequency, TCR[PRESCALE], and the contents of the CCR/CCR1 registers (SCKSET, SCKHLD, SCKDIV), and determine whether a different clock source or divider configuration could achieve a duty cycle closer to 50/50.   BR, Petr
記事全体を表示
IW612 working on IMX95-19x19 EVK board based on Android 16 In default, IMX95-19x19 EVK board enables the PCIe M.2 interface for Wi-Fi modules. But for SDIO interface M.2 Wi-Fi module, we could not use it directly. This doc is a step by step guide about how to make IW612 SDIO M.2 module(Murata 2EL) working on IMX95-19x19 EVK board based on Android 16. 1.Download I.MX Android BSP package, copy with scp to VMSIS. 16.0.0_1.4.0_ANDROID_SOURCE 2.Decompressing android bsp tar -xzf imx-android-16.0.0_1.4.0.tar.gz 3. source ./imx_android_setup.sh to download Android source code. 4.Prepare cross compiler GCC cross compiler: Download the tool chain for the AArch32 and AArch64 on: Arm GNU Toolchain I download the latest version: Arm GNU Toolchain 15.3.rel1 Need to pay attention, for I.MX95, need both 64 bit and 32 bit GCC compile tool. 64bit: arm-gnu-toolchain-15.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz 32 bit: arm-gnu-toolchain-15.3.rel1-x86_64-arm-none-eabi.tar.xz For AArch64 toolchain nxf93258@lsv051430:~/GCC_cross_compile_toolchain$sudo tar -xvJf arm-gnu-toolchain-15.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt/ nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$export AARCH64_GCC_CROSS_COMPILE=/opt/arm-gnu-toolchain-15.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- For 32bit toolchain: nxf93258@lsv051430:~/GCC_cross_compile_toolchain$sudo tar -xvJf arm-gnu-toolchain-15.3.rel1-x86_64-arm-none-eabi.tar.xz -C /opt/ nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ export AARCH32_GCC_CROSS_COMPILE=/opt/arm-gnu-toolchain-15.3.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi- 5.Set the external clang, kernel-build-tools, rust, and clang-tools tools for kernel building: nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ sudo ./device/nxp/common/tools/setup_android_kernel_prebuilts.sh 6.Set up the environment for building. This only configures the current terminal, if change to another terminal need to re-run the configurations. nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ source build/envsetup.sh 7.Execute the Android lunch command for i.MX95-EVK. nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$lunch evk_95-nxp_stable-userdebug 8.Optional Steps: Execute the imx-make.sh script to finish the whole images compiling. Or you can follow below steps to only build required images. nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ ./imx-make.sh -j4 2>&1 | tee build-log.txt 9.Modify the device tree to disable pcie0 and enable usdhc3 like below: ~/Android/imx-android-16.0.0_1.4.0/android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale$ git diff diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts index 69508a66f1c8..dfa1d3d51a9c 100644 --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts @@ -26,10 +26,19 @@ / { aliases { mmc0 = &usdhc1; mmc1 = &usdhc2; + mmc2 = &usdhc3; serial0 = &lpuart1; ethernet0 = &enetc_port0; ethernet1 = &enetc_port2; }; + + usdhc3_pwrseq: usdhc3_pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usdhc3_pwrseq>; + post-power-on-delay-ms = <100>; + }; + bt_sco_codec: audio-codec-bt-sco { #sound-dai-cells = <1>; @@ -651,7 +660,7 @@ &pcie0 { reset-gpio = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>; vpcie-supply = <&reg_pcie0>; supports-clkreq; - status = "okay"; + status = "disable"; }; &pcie1 { @@ -733,6 +742,22 @@ &usdhc2 { status = "okay"; }; +&usdhc3 { + pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; + pinctrl-0 = <&pinctrl_usdhc3>; + pinctrl-1 = <&pinctrl_usdhc3_100mhz>; + pinctrl-2 = <&pinctrl_usdhc3_200mhz>; + pinctrl-3 = <&pinctrl_usdhc3>; + mmc-pwrseq = <&usdhc3_pwrseq>; + vmmc-supply = <&reg_pcie0>; //Both PCIE0 and USDHC3 use same power supply. + bus-width = <4>; + keep-power-in-suspend; + non-removable; + wakeup-source; + status = "okay"; +}; + + &enetc_port0 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enetc0>; @@ -1225,6 +1250,45 @@ IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e >; }; + + pinctrl_usdhc3_pwrseq: usdhc3pwrseq { + fsl,pins = < + IMX95_PAD_XSPI1_SCLK__GPIO5_IO_BIT9 0x31e + >; + }; + + pinctrl_usdhc3: usdhc3grp { + fsl,pins = < + IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e + IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e + IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e + IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e + IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e + IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e + >; + }; + + pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp { + fsl,pins = < + IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e + IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e + IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e + IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e + IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e + IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e + >; + }; + + pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp { + fsl,pins = < + IMX95_PAD_SD3_CLK__USDHC3_CLK 0x15fe + IMX95_PAD_SD3_CMD__USDHC3_CMD 0x13fe + IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x13fe + IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x13fe + IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x13fe + IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x13fe + >; + }; }; &thermal_zones { 10.Build dtbo image. Need about 40 minutes. DTBO image holds the device tree binary of the board. nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ source build/envsetup.sh nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ lunch evk_95-nxp_stable-userdebug nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$./imx-make.sh dtboimage -j4 Then you will see that the dtbo images time stamp are updated as below: Christine_Li_0-1786168405295.png Below info is for your reference. ~/Android/imx-android-16.0.0_1.4.0/android_build/device/nxp/common/build/dtbo.mk This makefile includes the logic how to pack dtbo image. ~/Android/imx-android-16.0.0_1.4.0/android_build/device/nxp/imx9/evk_95/SharedBoardConfig.mk Christine_Li_1-1786168463709.png  This Macro: SUPPORT_GBL is not enabled in default, so still use dtbo image for the device tree. ~/Android/imx-android-16.0.0_1.4.0/android_build/device/nxp/imx9/evk_95/BoardConfig.mk Christine_Li_2-1786168477241.png  Wi-Fi/Bluetooth FW located here: Christine_Li_3-1786168507234.png  Wi-Fi/Bluetooth driver located here: Christine_Li_4-1786168518852.png Can modify the Makefile accordingly if needed. After compiled, the Wi-Fi driver and cfg80211.ko is located here: Christine_Li_5-1786168540709.png 11.Download prebuilt Image and decompress it. 16.0.0_1.4.0_DEMO_95//Pay attention to the version, need to match with our Android Source code download version. 12.Replace dtbo image. Rename the original dtbo-imx95.img to dtbo-imx95_original.img in the prebuilt image directory to be a backup. Then copy the dtbo-imx95.img from the remote android source code compiled directory: ~/Android/imx-android-16.0.0_1.4.0/android_build/out/target/product/evk_95/dtbo-imx95.img to the prebuilt image directory. Like below: Christine_Li_6-1786168893998.png 13.Flash images into board. Change the I.MX95-19*19-EVK board's SW7 to 1001 (from 1-4 bit) to enter serial download mode, then connect the board's USB1 port with type C cable to Windows PC. Download the UUU binary file from GitHub: Releases · nxp-imx/mfgtools Open the cmd interface in administrator mode, and enter to the prebuilt image directory. Flash the images into I.MX95-19*19-EVK board with below command: uuu_imx_android_flash.bat -f imx95 -a -e -u trusty-dual For the details of each parameter, can refer to: Android Quick Start Guide 14.Verify Wi-Fi and Bluetooth functions. After flash finished successfully, power off the board and change the board's SW7 to switch the board back to 1010 (form 1-4 bit) to enter eMMC boot mode. Check dmesg logs to confirm IW612 Wi-Fi driver is loaded successfully: Christine_Li_7-1786169134244.png   Check Wi-fi and Bluetooth work as expected in UI.  Can use this application: scrcpy on windows instead of connecting a LCD. Christine_Li_8-1786169192905.png Christine_Li_9-1786169200898.png This guide can also be a reference for other M.2 Wi-Fi modules with SDIO interface working on I.MX95 19*19-EVK board with Android or Linux OS. Reference: Android Quick Start Guide Android User's Guide Linux-Kernel Archive: [PATCH V3 2/3] arm64: dts: imx95-15x15-evk: Disable PCIe bus in the default dts Finished by Christine.Li. Aug 5 2026.
記事全体を表示
A2DP test on IW612+I.MX8MPlus-EVK L6.6.52 This doc is a brief step by step introduction for how to play music through A2DP on IW612 + I.MX8MPlus-EVK based on L6.6.52. Step 1: Load WiFi/Bluetooth Driver • NXP i.MX Release Distro 6.6-scarthgap imx8mpevk ttymxc1 imx8mpevk login: root root@imx8mpevk:~# modprobe moal mod_para=nxp/wifi_mod_para.conf root@imx8mpevk:~# root@imx8mpevk:~# dmesg | grep wlan [ 562.728200] wlan: Loading MWLAN driver [ 562.728788] wlan: Register to Bus Driver... [ 562.730460] wlan: Enable TX SG mode [ 562.730464] wlan: Enable RX SG mode [ 563.554778] wlan: uap%d set max_mtu 2000 [ 563.622367] wlan: version = SDIW612---18.99.3.p21.10-MM6X18505.p4-GPL-(FP92) [ 563.625611] wlan: Register to Bus Driver Done [ 563.625622] wlan: Driver loaded successfully root@imx8mpevk:~#modprobe btnxpuart root@imx8mpevk:~# hciconfig -a hci0: Type: Primary Bus: UART BD Address: D0:17:69:EE:71:4F ACL MTU: 1021:7 SCO MTU: 120:6 DOWN RX bytes:774 acl:0 sco:0 events:48 errors:0 TX bytes:496 acl:0 sco:0 commands:47 errors:0 Features: 0xbf 0xfe 0x8f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT • Step 2: Up BT interface and enable the power save feature root@imx8mpevk:~# hciconfig hci0 up root@imx8mpevk:~# hciconfig hci0 piscan root@imx8mpevk:~#hciconfig hci0 noencrypt root@imx8mpevk:~# hciconfig -a hci0: Type: Primary Bus: UART BD Address: D0:17:69:EE:71:4F ACL MTU: 1021:7 SCO MTU: 120:6 UP RUNNINGPSCAN ISCAN RX bytes:1900 acl:0 sco:0 events:109 errors:0 TX bytes:1365 acl:0 sco:0 commands:108 errors:0 Features: 0xbf 0xfe 0x8f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT Name: 'imx8mpevk' Class: 0x200000 Service Classes: Audio Device Class: Miscellaneous, CI Version: 5.4 (0xd) Revision: 0x8300 LMP Version: 5.4 (0xd) Subversion: 0x1015 Manufacturer: NXP Semiconductors (formerly Philips Semiconductors) (37) • Step 3: Scan, Pair and Connect to Headset root@imx8mpevk:~# bluetoothctl hci0 new_settings: powered connectable discoverable bondable ssp br/edr le secure-conn cis-central cis-peripheral Agent registered [CHG] Controller D0:17:69:EE:71:4F Pairable: yes [bluetooth]# power on Changing power on succeeded [bluetooth]# default-agent Default agent request successful [bluetooth]# agent on Agent is already registered [bluetooth]# scan on [NEW] Device B1:96:11:68:9C:09 联想thinkplus-HE05X II代 [bluetooth]# scan off [bluetooth]# pair B1:96:11:68:9C:09 Attempting to pair with B1:96:11:68:9C:09 hci0 device_flags_changed: B1:96:11:68:9C:09 (BR/EDR) supp: 0x00000000 curr: 0x00000000 [DEL] Device 67:02:B9:7C:ED:B5 67-02-B9-7C-ED-B5 [DEL] Device 80:F4:16:4C:48:F2 HI-Apiyoo-12MIQ001981 hci0 B1:96:11:68:9C:09 type BR/EDR connected eir_len 34 [CHG] Device B1:96:11:68:9C:09 Connected: yes hci0 new_link_key B1:96:11:68:9C:09 type 0x04 pin_len 0 store_hint 1 [CHG] Device B1:96:11:68:9C:09 Bonded: yes [DEL] Device 6A:98:7A:08:0F:B8 6A-98-7A-08-0F-B8 [CHG] Device B1:96:11:68:9C:09 ServicesResolved: yes [CHG] Device B1:96:11:68:9C:09 Paired: yes Pairing successful5X II代]# [DEL] Device 6C:59:25:E5:66:77 6C-59-25-E5-66-77 [DEL] Device 61:CC:7D:CE:20:4E 61-CC-7D-CE-20-4E [DEL] Device 64:C1:4B:76:C1:80 64-C1-4B-76-C1-80 [DEL] Device 72:50:16:14:52:A6 72-50-16-14-52-A6 hci0 B1:96:11:68:9C:09 type BR/EDR disconnected with reason 2 [CHG] Device B1:96:11:68:9C:09 ServicesResolved: no [CHG] Device B1:96:11:68:9C:09 Connected: no [bluetooth]#trust B1:96:11:68:9C:09 [CHG] Device B1:96:11:68:9C:09 Trusted: yes Changing B1:96:11:68:9C:09 trust succeeded [bluetooth]#connect B1:96:11:68:9C:09 Attempting to connect to B1:96:11:68:9C:09 hci0 B1:96:11:68:9C:09 type BR/EDR connected eir_len 34 [CHG] Device B1:96:11:68:9C:09 Connected: yes [NEW] Endpoint /org/bluez/hci0/dev_B1_96_11_68_9C_09/sep1 [NEW] Endpoint /org/bluez/hci0/dev_B1_96_11_68_9C_09/sep2 [NEW] Transport /org/bluez/hci0/dev_B1_96_11_68_9C_09/sep1/fd0 [CHG] Transport /org/bluez/hci0/dev_B1_96_11_68_9C_09/sep1/fd0 Delay: 0x05dc (1500) Connection successfulII代]# [CHG] Device B1:96:11:68:9C:09 ServicesResolved: yes [联想thinkplus-HE05X II代]#quit • Step 4: Start pipewire and wireplumber Service then list and choose default Audio Source/Sink Card root@imx8mpevk:~#systemctl --user start pipewire wireplumber root@imx8mpevk:~#wpctl status PipeWire 'pipewire-0' [1.0.5, root@imx8mpevk, cookie:831282980] Clients: 32. WirePlumber [1.0.5, root@imx8mpevk, pid:1528] 40. WirePlumber [export] [1.0.5, root@imx8mpevk, pid:1528] 87. wpctl [1.0.5, root@imx8mpevk, pid:1552] Audio -Devices: 41. Built-in Audio [alsa] 42. Built-in Audio [alsa] 43. Built-in Audio [alsa] 44. Built-in Audio [alsa] 45. Built-in Audio [alsa] 81. 联想thinkplus-HE05X II代 [bluez5] -Sinks: 47. Built-in Audio Mono [vol: 0.40] 48. Built-in Audio Stereo [vol: 0.40] 50. Built-in Audio Stereo [vol: 0.40] 58. Built-in Audio Digital Stereo (IEC958) [vol: 0.40] * 82. 联想thinkplus-HE05X II代 [vol: 0.40] -Sources: 46. Built-in Audio Mono [vol: 1.00] 49. Built-in Audio Stereo [vol: 1.00] 51. Built-in Audio Stereo [vol: 1.00] * 59. Built-in Audio Digital Stereo (IEC958) [vol: 1.00] -Filters: -Streams: Video -Devices: 52. mxc-isi-m2m_v1 [v4l2] 53. vsi_v4l2enc [v4l2] 54. vsi_v4l2dec [v4l2] Streams: Settings Default Configured Devices: root@imx8mpevk:~#wpctl set-default 82 root@imx8mpevk:~#wpctl set-default 59 root@imx8mpevk:~# wpctl status PipeWire 'pipewire-0' [1.0.5, root@imx8mpevk, cookie:831282980] Clients: 32. WirePlumber [1.0.5, root@imx8mpevk, pid:1528] 40. WirePlumber [export] [1.0.5, root@imx8mpevk, pid:1528] 87. wpctl [1.0.5, root@imx8mpevk, pid:1572] Audio 41. Built-in Audio [alsa] 42. Built-in Audio [alsa] 43. Built-in Audio [alsa] 44. Built-in Audio [alsa] 45. Built-in Audio [alsa] 81. 联想thinkplus-HE05X II代 [bluez5] 47. Built-in Audio Mono [vol: 0.40] 48. Built-in Audio Stereo [vol: 0.40] 50. Built-in Audio Stereo [vol: 0.40] 58. Built-in Audio Digital Stereo (IEC958) [vol: 0.40] * 82. 联想thinkplus-HE05X II代 [vol: 0.40] 46. Built-in Audio Mono [vol: 1.00] 49. Built-in Audio Stereo [vol: 1.00] 51. Built-in Audio Stereo [vol: 1.00] * 59. Built-in Audio Digital Stereo (IEC958) [vol: 1.00] 分区Bluetooth 的第4 页 * 59. Built-in Audio Digital Stereo (IEC958) [vol: 1.00] Streams: Video 52. mxc-isi-m2m_v1 [v4l2] 53. vsi_v4l2enc [v4l2] 54. vsi_v4l2dec [v4l2] Streams: Settings Default Configured Devices: 0. Audio/Sink bluez_output.B1_96_11_68_9C_09.1 1. Audio/Source alsa_input.platform-sound-xcvr.iec958-stereo Step 5: Copy、Play and Enjoy Music Drag the music file yesterday-once-more.wavto I.MX8MP-EVK board by connecting Windows PC and I.MX8MP-EVK board into one local area network. root@imx8mpevk:~# pw-play -v ./yesterday-once-more.wav sndfile: opened file "yesterday-once-more.wav" format 00010002 channels:2 rate:44100 sndfile: using default channel map: FL,FR PCM: fmt:s16 rate:44100 channels:2 width:2 rate:44100 latency:4410 (0.100s) connecting playback stream; target=(null) stream state changed unconnected -> connecting stream param change: Spa:Enum:ParamId:Latency stream param change: Spa:Enum:ParamId:Tag stream param change: Spa:Enum:ParamId:Props stream properties: application.name = "pw-play" node.name = "pw-play" media.software = "Lavf58.29.100" media.format = "WAV (Microsoft)" node.rate = "1/44100" node.latency = "4410/44100" media.type = "Audio" media.category = "Playback" media.role media.filename = "yesterday-once-more.wav" media.name = "yesterday-once-more.wav" stream.is-live = "true" node.want-driver = "true" node.autoconnect = "true" media.class = "Stream/Output/Audio" remote 0 is named "pipewire-0" stream state changed connecting -> paused stream param change: Spa:Enum:ParamId:Props stream param change: Spa:Enum:ParamId:Latency stream param change: Spa:Enum:ParamId:Latency stream param change: Spa:Enum:ParamId:Format stream state changed paused -> streaming stream set volume to 1.000 -success stream node 88 stream time: now:0 rate:1/48000 ticks:0 delay:9248 queued:0 buffered:0 buffers:0 avail:2 size:0 stream time: now:4821374572568 rate:1/48000 ticks:49152 delay:9248 queued:1882 buffered:32 buffers:1 avail:1 size:1882 stream time: now:4822355905886 rate:1/48000 ticks:96256 delay:9248 queued:1882 buffered:32 buffers:1 avail:1 size:1882 stream time: now:4823379905870 rate:1/48000 ticks:145408 delay:9248 queued:1881 buffered:32 buffers:1 avail:1 size:1881 Finished By Christine.Li Jul 22th,2026.
記事全体を表示
Understanding I²C Buffers and Static Voltage Offset (SVO): Why Your Bus May Fail I²C communication is widely used due to its simplicity, but when the system grows (more devices, longer traces, different voltage domains), communication issues may appear. One common root cause is the incorrect use of I²C buffers or level translators. This post explains: How I²C logic levels really work Why buffers are needed Types of I²C Buffer Technologies How Static Voltage Offset (SVO) works Common design mistakes to avoid How I²C logic levels really work I²C does not use fixed voltages like 0 V or 5 V to define logic states. Instead, it uses thresholds relative to VCC: Logic 0 (LOW): below ~30% of VCC Logic 1 (HIGH): above ~70% of VCC Undefined region: between 30%–70% → signal is unreliable ErikaC_0-1780606331928.png ErikaC_0-1785342135078.png In real systems, signal levels may not behave ideally. Due to: Different driver strengths Load variations Buffer offset behavior You may observe three voltage levels, even though the protocol only defines two logic states. This can lead to misinterpretation of signals. ErikaC_1-1780606357974.png We will explore this behavior in more detail in the following sections, especially when analyzing how I²C buffers and offset mechanisms work. Why buffers are needed You should consider an I²C buffer when: Bus capacitance exceeds ~400 pF Long PCB traces or cables are used Multiple devices are connected Different voltage domains are required Isolation between sections is needed Buffers divide the system into smaller segments and improve signal integrity. For a deeper understanding, refer to the training: The Ins and Outs of I²C Bus Buffers Types of I²C Buffer Technologies Different buffer architectures solve these challenges in different ways: Static Offset: Introduces a fixed voltage offset on one side of the bus, enabling direction detection. Incremental Offset: Adds a small dynamic voltage shift (~100 mV), allowing symmetrical bidirectional operation. Amplifier: Boosts sink current instead of shifting voltage, helping weak drivers control heavier loads. In this post, we will focus specifically on Static Offset buffers, as they are widely used and often misunderstood in system design. Static Offset Buffer Characteristics Static Offset buffers are commonly used due to their robust behavior: Fully bidirectional and support multi-master operation, including clock stretching and do not generate any ‘glitches’. Isolate bus segments electrically, preventing capacitance and loading on one side from affecting the other side. Each side operates independently with its own rise time and pull-up network. Regenerate signals, producing clean LOW levels independent of the input LOW amplitude. Use a fixed Static Voltage Offset (SVO), creating a slightly higher LOW level on one side of the buffer. This offset allows the buffer to determine the origin of a LOW signal and prevents latching. Weaknesses of Static Offset Buffers Require specific design rules due to their special offset voltage levels. Static Offset ports cannot be connected together on the same bus segment. Only one offset port should exist per bus segment. Add propagation delay, which must be considered in timing analysis. Multiple buffers can reduce the maximum achievable I²C bus speed The main challenge in I²C buffers is that the bus is bidirectional. Both master and slave can pull the line LOW. By introducing a fixed voltage offset, the buffer can distinguish which side initiated the LOW condition and correctly propagate the signal across the bus. How Static Voltage Offset (SVO) works Static Voltage Offset introduces an intentional voltage offset, so a LOW level is not always represented by 0 V. Instead, the buffer creates two valid LOW levels, both within the I²C specification. To achieve this, the input and output logic levels on the special side of the buffer are intentionally designed to be different. ErikaC_0-1785263036476.png   The key concept is that the special output LOW voltage (VOL) is set slightly higher than the corresponding input HIGH threshold (VIH): For example: Special output VOL ≈ 0.7 V Special input VIH ≈ 0.55 V When the buffer drives the special side LOW at approximately 0.7 V, that voltage is still considered a valid LOW by other I²C devices on the bus. However, for the buffer's own special input, 0.7 V is interpreted as a HIGH because it is above its VIH threshold. As a result, the buffer's output cannot feed back into its own input, preventing the latching condition commonly found in simple bidirectional buffers. ErikaC_1-1785263096789.png This enables the buffer to distinguish between two conditions: State 1: The voltage is between the special input threshold (VIL) and the offset level (VOL/SVO). This indicates that the LOW originated from one side of the buffer. State 2: The voltage is pulled much closer to 0 V, below the special threshold. This indicates that the LOW originated from the opposite side of the buffer. By monitoring these voltage levels, the buffer can determine where the LOW signal originated (Side A or Side B). Once the direction is identified, the buffer can correctly propagate the signal to the other side while avoiding feedback, latching, and communication conflicts. But, How Does the Buffer Determine the Signal Direction? The Buffer uses an internal voltage offset to automatically determine the direction of I²C signal propagation. The offset appears on the opposite side of the device that is actively pulling the bus LOW, allowing the buffer to identify the signal source and maintain proper bidirectional operation. ErikaC_0-1785352884818.png The buffer continuously monitors the voltage present on both sides and compares it against the internal offset thresholds. Case 1: LOW originated from the Non-Offset side (A → B) A device on Side A pulls the line LOW. The buffer propagates this LOW to Side B while adding the static offset: Side A = LOW Side B = LOW + Offset ErikaC_0-1785340210113.png As a result: Input = LOW Output = OFFSET The presence of the offset voltage indicates that the signal originated from the Non-Offset side and is being propagated toward the Offset side. ErikaC_0-1785341778973.png   Case 2: LOW originated from the Offset side (B → A) A device on Side B pulls the line LOW. The buffer recognizes that the voltage has been driven below the offset threshold and propagates a true LOW toward Side A: Side B ≈ LOW Side A ≈ LOW As a result: Input = LOW Output = LOW The absence of an offset on the output indicates that the signal originated from the Offset side and is being propagated toward the Non-Offset side. ErikaC_1-1785341802204.png   INPUT OUTPUT DIRECTION LOW LOW B SIDE TO A SIDE LOW OFFSET A SIDE TO B SIDE   Common design mistakes to avoid When using I²C buffers that implement Static Voltage Offset (SVO), it is important to carefully consider both device selection and system-level design. This is because not all buffers use the same offset value. Typically, the SVO can vary between approximately 0.1 V and 0.6 V, depending on the internal design of each device. This variation directly affects how LOW levels are interpreted and how signals are propagated between segments of the bus, which can ultimately impact the reliability of bidirectional communication. Another important aspect is that the offset is not always located on the same side of the buffer. In some devices, the offset is applied on Side B, while in others it is on Side A. There are even cases where the offset may dynamically change sides depending on the operating conditions. For this reason, it is essential to fully understand the internal behavior of the selected buffer in order to avoid unexpected system behavior. The easiest way to verify this is by reviewing the device datasheet and identifying whether it specifies a parameter such as the VOL–VILC difference, which represents the difference between the LOW-level output voltage and the LOW-level input voltage during a contention condition. Voltage contention occurs when both sides of the buffer attempt to pull the line LOW at the same time but with different voltage levels or drive strengths. ErikaC_4-1780606435484.png Due to this variability, there is a very important design rule: SVO-based buffers must never be directly connected to each other, whether in series or in parallel. This means that you should not connect two buffer sides that both introduce a voltage offset, as their LOW levels will not align correctly. The reason for this limitation is that it can lead to errors in LOW-level propagation. In such cases, a LOW signal may propagate correctly in one direction but fail in the opposite direction, breaking the bidirectional behavior of the I²C bus, which is essential for proper communication. ErikaC_0-1780606934177.png   These diagrams show correct implementations of SVO-based I²C buffers. In these configurations, only one side of the system introduces a static voltage offset, allowing the buffer to properly distinguish the origin of the LOW signal. This ensures correct bidirectional communication, stable signal propagation, and prevents contention or oscillation issues. ErikaC_5-1780606454839.png     ErikaC_6-1780606463739.png   ErikaC_7-1780606471571.png   ErikaC_8-1780606485773.png These diagrams illustrate incorrect configurations where two SVO-based buffers are directly connected. In this case, both sides introduce different LOW offset levels, preventing proper alignment of logic thresholds. As a result, the buffer may fail to correctly detect the signal origin, leading to incomplete LOW propagation, loss of bidirectional behavior, and potential communication failures. ErikaC_9-1780606500895.png   ErikaC_10-1780606511051.png   I2C
記事全体を表示
Example SJA1110 FreeRTOS lwIP SJA1110-EVM S32DS 3.5 RTD 1.0.2 ********************************************************************************* * Detailed Description: * Updated the example lwip_FreeRTOS_SJA1110 for board SJA1110-EVM * to enable ping from the command window, from all applicable ports * *ping 192.168.0.200 * *Pinging 192.168.0.200 with 32 bytes of data: *Reply from 192.168.0.200: bytes=32 time=2ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 * *Ping statistics for 192.168.0.200: * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), *Approximate round trip times in milli-seconds: * Minimum = 1ms, Maximum = 2ms, Average = 1ms * * Installed packages to S32DS 3.5 update 14: * SW32SJA11xx_S32DS_3.5.0_RFP_D2206.zip * SJA11XX_RTD_4.4_1.0.1_P02_HF01_D2510_DesignStudio_updatesite.zip * SW32SJA1110_XJA11XX_ETH_PHY_4.4_1.0.8_CD01_D2509_DesignStudio_updatesite.zip * SJA11XX_ETH_SWITCH_4.4_1.0.2_CD01_D2509_DesignStudio_updatesite.zip * SW32SJA11xx_FreeRTOS_11.1.0_0.8.0_CD2_D2411_DesignStudio_updatesite.zip * SJA11XX_TCPIP_2.0.0_CD01_D2510_DesignStudio_updatesite.zip * * EVB: * - Except SW15, All DIP switches accordingly to um575112-AH1901 SJA1110 - EVM User Manual(1.2).pdf * - TJA1101 needs to be in Managed Operation, RMII mode (50 MHz output on REF_CLK) * SW15.1-8: ON OFF ON OFF ON OFF OFF ON * * Configuration: * - Updated switch configuration * - Updated phy configuration * - Fixed Mcu/McuModuleConfiguration/McuPowerControlUnit - 1V8 and 2V5 * - Fixed Eth configuration * * * * - TCPIP stack: enabled UDP_ECHO, etc. * - Added Gpio_Dio * - Added nvm_metadata * - MAC learning is disabled * - Added LED control via I2C GPIO expander * (adopted & fixed from SJA1110_gptp_ds example - SW32SJA11xx_M7_gPTP_1_0_0_D2411_DesignStudio_updatesite.zip) * * main.c * - Updated only the header * device.c/h * - adopted from SJA1110_gptp_ds example * test.c * - Removed the code that shuts down the TCP/IP stack after its predefined timeout * - Added LED ALIVE * - Added debug stuff * /board + /pca950x + /swi2c * - adopted from SJA1110_gptp_ds example * * ----------------------------------------------------------------------------- * Test HW: SJA1110-EVM SCH REV B2 * MCU: SJA1110 * Debugger: Lauterbach TRACE32 * Target: RAM or external FLASH (flash_image.bin generated) * EVB connection: any port (excluding SFP cages) <-> RDDRONE T1ADAPT (on ports where applicable) <-> USB-to-Ethernet adapter <-> Laptop DELL, Windows 11
記事全体を表示
LLCE example and U-boot Hello. I'm trying to make the LLCE examples work on the Goldbox. I modified the CAN2CAN example a little bit, and it works if I debug it from S32DS. If I try to run it from U-boot, however, it executes, but hangs U-boot itself. These are the commands I'm running: dcache off; mw.q 0x34000000 0x0 0x100000; dcache on fatload mmc 0:2 ${loadaddr} /llce.elf bootm7 ${loadaddr} VTABLE I can see the CAN traffic on the bus, so the example is running, but U-boot hangs and is not able to accept commands anymore. After some debugging, I was able to trace the problem to the PlatformInit() call, and in particular the code to set the clock. If I remove that code, however, the example does not work anymore. Do you have any suggestions? Re: LLCE example and U-boot Hello, @GioMusto  Thanks for your reply. Yes, it is for S32G2, not G3, but the method introduced is similar. Since it is based on early version software packages, it could not be considered as a step by step guide when using recent version software combinations. BR Chenyin Re: LLCE example and U-boot Hi @chenyin_h, thanks for your reply. I see the guide you posted is for the S32G2. Is it the same for S32G3, or are there some differences? Do you have any suggestion on things to keep an eye on? Common problems, and so on. Re: LLCE example and U-boot Hello, @GioMusto  Thanks for your post. The issue you mentioned may be caused clock or other resource confliction between M and A side. 1. On S32G product, under default settings, the BSP running on A53 side is designed under the assumption that it has exclusive access to the system, and therefore does not consider potential conflicts introduced by other software components, while in your M core application, it may also touch critical resources like clock/memory, etc. You have to careful about every part of the code, to avoid any possible confliction/re-configuration for critical resources. 2. For running both M7 application and Linux BSP simultaneously, the recommended way is to firstly running a M7 bootloader to manage the resources, as introduced via AN13750  BR Chenyin Re: LLCE example and U-boot I'm trying to build the M7 bootloader by following AN13750 and the "System-Level Bootloader Integration Example for S32G3XX". I managed to compile the bootloader (with some difficulties, since I'm missing the SAF package), but now I'm stuck with the IVT tool in S32DS. When I create a new project, select S32G399A, Cortex-M7_0, and create a configuration, I get the error "IVT tool does not support the current processor. The same is true for DCD, QuadSPI, DDR and eFuse (see screenshot). What am I doing wrong? IVT_error.png Re: LLCE example and U-boot Hello, @GioMusto  Thanks for your reply. 1. Commonly, I suggest using S32DS3.5.x(for example, 3.5.14) for working with S32G(mentioned in release notes of S32G RTD release), and make sure that the following packages are installed at least:(RTD and development package) chenyin_h_0-1786010049364.png 2. To simplify the process, you may import an example project into the S32DS, and then open the IVT tool, for example: chenyin_h_1-1786010241259.png Then have a try if the IVT tool could be used for generating blob based on your own images. BR Chenyin
記事全体を表示
RW612 WiFi Init stuck on HAL_ImuLinkIsUp() I am trying to run the MQTT example on a custom board. The module used is ublox IRIS-W106-30B. I followed the instructions to use j-link to install the wifi fw blob serperatly. However, I am getting stuck in an infinite loop in WPL_Init().   natered21_0-1785877418073.png I was also unable to initialize the BLE due to similar issue. SDK 25.09.00 using MCUXpresso  Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() Yes, I am able to run my normal application code, log to UART etc.  Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() Hi, Are you able to test a simple Hello World example? Also, have you already applied the required modifications to enable your module? Please refer to the following article for guidance. Regards, Daniel. Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() Are you using the RD-RW61X-BGA SDK or the FRDM-RW612 SDK? Which files did you modify to port the original example to your module? Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() If I'm understanding correctly, you're able to run the Wi-Fi and Bluetooth examples on your custom board without any issues. The problem appears when you start integrating or porting the networking functionality into your own application. My recommendation is to use the MQTT example as the foundation for your application. If your use case requires Wi-Fi and BT/BLE to run simultaneously, then it would be better to start from one of the coexistence examples and add your application-specific functionality on top of it, rather than trying to add coexistence support to an existing custom application afterward. By the way, SDK 25.09 is already three releases behind. I would recommend upgrading to the latest SDK 26.06 before continuing. Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() SDK_2.x_RW610 From the mqtt example I copied everything from "main_task" and after into my existing project. This leave the hardware init, as a major difference. I am unable to identify which aspects from the example are causing IMU to not initialize.  I can run the base example project on my custom board but am unable to port it into existing project. 
記事全体を表示
S32G-VNP-RDB3: Onchip debugging support Hello, I want to debug my AUTOSAR Operating System based application on following environment. 1) Board Name: S32G-VNP-RDB3 2) Microcontroller Variant: S32G399 3) Cortex-M7 Cores 4) Host: Windows Is there any on-chip debugging support enabled in the mentioned board where I can connect without any external debugger or probe. If on-chip debugging support is not available on this board then can I debug with S32 debug probe (H/W) and s32 design studio IDE (S/W) ? With Regards, Madhusudan Gupta Re: S32G-VNP-RDB3: Onchip debugging support Hello, @madhusudangupta007  Thanks for your post. 1. There is no onchip debugger on RDB3, so it is not supported to directly debug the RDB3 via the USB port. 2. Commonly, the Lauterbach TRACE32 Debug is used for debugging the S32G products, besides, the S32 Debug Probe which is provisioned by NXP(S32 Debug Probe | NXP Semiconductors) is also used. 3. Yes, as mentioned before, the S32 debug probe(HW) and S32 Design Studio(IDE) could be used together for debugging the RDB3 board.    BR Chenyin
記事全体を表示
i2c problems during wakeup frum suspend A question for the experts out there. I have a circuit in which several push-button switches are connected to a GPIO expander. My current system is based on an IMX8MP, to which this GPIO expander is connected via I²C. This expander has an interrupt line to the IMX8MP. Often, when I put the system into suspend mode and press one of the push buttons (the expander is also marked as a wake-up source in the device tree), I receive this message hundreds or even thousands of times as soon as the system comes out of suspend: [ 117.113106] pca953x 3-0076: failed reading register. I know there was already a patch for a similar issue in the i2c-imx.c driver, and I’ve applied it. However, it isn’t having the desired effect. What can I do about this? P.S. It doesn’t happen all the time, but it can be reproduced relatively quickly. Best regards R. Re: i2c problems during wakeup frum suspend I use Kernel Version 6.6.23 Re: i2c problems during wakeup frum suspend Hi @RRD101  Based on your description, it seems like you could try this commit. Also, which kernel version are you using? Best Regards, Zhiming
記事全体を表示
S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way Setup S32K396, no HSE FW ever installed, no secure boot, no ADKP. FS26 with 200ms watchdog What happened I was installing the AB_SWAP pink image over the MU interface 1. Programmed the HSE FW usage flag in UTEST at 0x1B000000. No other UTEST location touched. SBAF had not programmed it itself despite `FW_USAGE_FLAG_PROGRAM` being set in my boot config. 2. Wrote 0xA5 into DCMRWP1 (0x402AC400) bits 31 to 24 and issued a functional reset. 3. Ran the handshake on MU0 ch0: got 0xFF00F00F, replied 0xF0F00F0F, got 0xDADABABA, wrote the pink image address. so SBAF started programming the firmware. 4. Sometime after that, everything halted. Nothing more on the UART console. I power-cycled after ~5 minutes. Since then the board produces no console output at all, and I can no longer debug it the way I normally do: J-Link reports "Locked S32K3xx device detected" and asks for the ADKP. Or reports "Power-up of DAP failed" (See attached file). So I cannot read GPR3, DCMRWP1 or UTEST any more. I never provisioned an ADKP and never requested a life-cycle advance. Questions 1. Could the LC have advanced by itself? 2. Or is this recovery mode? In JTAG recovery mode on a CUST_DEL device, can a J-Link connection present as "locked / password required"? Figure 12 in the HSE_B Firmware Reference manual shows that path as waiting for a debugger without authentication. 3. What can I still test before scrapping the part? Above all: is there any way to read the current LC state over the debug interface when the host core is not released? Or is it possible another debug method using Trace32 would work better? Re: S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way 1) No, it cannot. It can be programmed either by user directly to UTEST (when HSE FW is not used) or with using of HSE service (when HSE FW is used). 2) I don’t think so, although I don’t have experience with J-Link. It is possible "Locked S32K3xx device detected" message Yes, the "Locked S32K3xx device detected" message can be a false positive caused by hardware (typically power) rather than an actual security lock. I would recommend to discuss it with Segger: https://www.segger.com/support/technical-support/ Even the device would be in JTAG recovery mode, if still in CUST_DEL life cycle, you still should be able to connect by debugger, download SW and so. 3) I would try to attach or attach just after POR, possibly erase application SW. Re: S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way What I've noticed now is that the 'RESET_RECOVERY_MODE' bit was not set in the BCW. Could not setting this bit in the BCW explain this behavior? Im a bit confused as to what setting this bit does. Will setting this bit enable recovery mode or disable it? In `Table 119. BCW bit mapping` in the HSE reference manual its written that 'RESET_RECOVERY_MODE' is "Used to disable entry into recovery mode because of consecutive resets. See Disable Entry into Reset Recovery Mode for more detail". Then In the chapter `2.6.1.3.3 Disable entry into reset recovery mode` in the HSE reference manual "Entry into recovery mode" is only true while 'RESET_RECOVERY_MODE == 1 AND DCMRWP1 (SBAF_REC_DIS_FRST or SBAF_REC_DIS_DRST) == 0'.  Re: S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way Thank you for your reply, David. Okay. I have reached out to Segger regarding the possibility of a falsely locked device and am awaiting a response. I connected using the J-Link debugger after a POR while shorting the reset pin. This is the log from that sequence: In this case, the HSE firmware is not installed, nor is the device locked. The error that remains from both scenarios is the DAP error. SEGGER J-Link Commander V9.18 (Compiled Feb 11 2026 16:34:58) DLL version V9.18, compiled Feb 11 2026 16:33:51 Connecting to J-Link via USB...O.K. Firmware: J-Link V10 compiled Jan 30 2023 11:28:07 Hardware version: V10.10 J-Link uptime (since boot): N/A (Not supported by this model) S/N: 50116795 License(s): GDB VTref=4.509V Type "connect" to establish a target connection, '?' for help J-Link>connect Please specify device / core. : S32K396_M7_0 Type '?' for selection dialog Device> Please specify target interface: J) JTAG (Default) S) SWD T) cJTAG TIF>S Specify target interface speed [kHz]. : 4000 kHz Speed> Device "S32K396_M7_0" selected. Connecting to target via SWD ConfigTargetSettings() start ConfigTargetSettings() end - Took 46us InitTarget() start SDA_AP detected Unlocking device if necessary... Device is not locked. Proceeding without the unlock procedure. Checking if debug access is already enabled... Debug access is not enabled yet. Performing enable debug access sequence... Debug access enabled Checking if HSE firmware is installed... HSE firmware not installed Checking if Cortex-M7_0 and Cortex-M7_1 are operating in lockstep mode Lock step mode enabled InitTarget() end - Took 45.5ms Found SW-DP with ID 0x6BA02477 DPIDR: 0x6BA02477 CoreSight SoC-400 or earlier AP map detection skipped. Manually configured AP map found. AP[0]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[1]: APB-AP (IDR: Not set, ADDR: 0x00000000) AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[3]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[5]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[6]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[7]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: Skipped ROMBASE read. CoreBaseAddr manually set by user AP[4]: Core found ConfigTargetSettings() start ConfigTargetSettings() end - Took 15us InitTarget() start SDA_AP detected Unlocking device if necessary... Device is not locked. Proceeding without the unlock procedure. Checking if debug access is already enabled... Core already enabled Checking if HSE firmware is installed... HSE firmware not installed Checking if Cortex-M7_0 and Cortex-M7_1 are operating in lockstep mode Lock step mode enabled InitTarget() end - Took 18.2ms Found SW-DP with ID 0x6BA02477 DPIDR: 0x6BA02477 CoreSight SoC-400 or earlier AP map detection skipped. Manually configured AP map found. AP[0]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[1]: APB-AP (IDR: Not set, ADDR: 0x00000000) AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[3]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[5]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[6]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[7]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: Skipped ROMBASE read. CoreBaseAddr manually set by user AP[4]: Core found ****** Error: DAP error while reading AIRCR. Error occurred: Could not connect to the target device. For troubleshooting steps visit: https://kb.segger.com/J-Link_Troubleshooting
記事全体を表示
KE1 ECC RAM Single Bit Corrrection Have a few questions regarding ECC. I am currently using the MCM_LMFAR to determine where the ECC triggered a fault and then using that address to read then write back to correct it. Questions: 1. Does the ECC have the ability to autocorrect bits? Or do I really need to perform this read/write to address to correct? 2. If there is not autocorrect, will I need to compensate for byte alignment when performing my read/write correction mechanism? Currently I am performing a 4-byte read/write at the address denoted by the MCM_LMFAR. I feel like this is dangerous as I am not sure the MCM_LMFAR will always show a 4-byte aligned address. Re: KE1 ECC RAM Single Bit Corrrection Hello @sean_dvorscak , Thank you for your post. Could you please let me know which specific device in the KE1 family you are using? This will help me locate the relevant documentation more accurately or perform validation using the same device. BR Celeste Re: KE1 ECC RAM Single Bit Corrrection It's a KE18F512VLH16. Thanks for your help. Re: KE1 ECC RAM Single Bit Corrrection One more question actually. The automatic HW ECC correction functionality is enabled by default? I don't really see any bits in the MCM registers that would suggest it's a feature that can be disabled/enabled. Re: KE1 ECC RAM Single Bit Corrrection Hello @sean_dvorscak , Thanks for your reply. So for your questions: 1. Does the ECC have the ability to autocorrect bits? Or do I really need to perform this read/write to address to correct? ->> Yes, ECC does support hardware correction for single-bit errors. So you should not need a software read/write sequence to obtain corrected data.  2. If there is not autocorrect, will I need to compensate for byte alignment when performing my read/write correction mechanism? Currently I am performing a 4-byte read/write at the address denoted by the MCM_LMFAR. I feel like this is dangerous as I am not sure the MCM_LMFAR will always show a 4-byte aligned address. ->> If implementing an optional scrub, please align the access according to the actual access size or scrub granularity, not blindly to the raw MCM_LMFAR value. Also don't use a fixed 4-byte access unless you first align the address appropriately and confirm the access size is valid. In fact, For multi-bit / non-correctable ECC events , do not assume a read/write can repair the data, you should treat it as data corruption and recover from a known-good source or reinitialize the affected memory as appropriate. Hope it helps. BR Celeste --------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the "ACCEPT AS SOLUTION" button. Thank you! --------------------------------------------------------------------------------------------------------------------- Re: KE1 ECC RAM Single Bit Corrrection Thanks for the confirmation and info. And yes, I am handling uncorrectable bit errors differently. Re: KE1 ECC RAM Single Bit Corrrection Yes, ECC checking/generation is enabled by default after reset. Re: KE1 ECC RAM Single Bit Corrrection Have more follow up questions. Does the hardware correct the data within the Memory Cell, or only on the Read Out Data? Example from AN5335, is the Read-out Data being corrected from 0->1? That would mean we need to write back the corrected value to RAM to actually clear it. sean_dvorscak_0-1785962043300.png We are concerned if the data in the RAM memory cell is not corrected, a single bit error could degrade to a double bit error. Re: KE1 ECC RAM Single Bit Corrrection Hello @sean_dvorscak , I noticed that this thread has already been closed. To help us better track and follow up on this issue, could you please create a new post? Thank you for your cooperation.   BR Celeste
記事全体を表示