Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
S32K148はセキュアブート機能を備えているが、JTAGを無効にするとブートローダーが起動しない。 NXP様、こんにちは。 弊社のK148には、ブートローダーとアプリケーションパーティションの2つのパーティションがあります。アプリケーションパーティションには、JTAGを無効にする機能があります。アプリケーションでJTAGを無効にすると、リセット後にブートローダーが起動せず、チップが動作不能になります。調査の結果、ブートローダーは32KBで、アドレス0x00から0x8000の範囲であることが判明しました。JTAGを無効にするには、アドレス0x408に0xFFu 、0xFFu 、 0xFFu 、 0xFFu 、 0xFCu 、 0x7Fu 、 0xFFu 、 0xFFuを書き込む必要があり、これによりフラッシュメモリの内容が変更されます。リセット後、CSEcがブートローダーに対して異なるboot_mac値を計算してしまうため、チップが動作不能になります。NXPは、この問題を解決するための成熟したソリューションを提供していますでしょうか?よろしくお願いいたします。 Re: S32K148有secureboot功能,但是bootloader在jtag关闭后起不来 こんにちは、 @lukaszadrapa 上記のマニュアルによると、 BOOT_MACは一度だけ書き込まれる不可逆的な値です。この値を変更できる公式APIはありますか?もしあれば、そのAPIを提供していただけますか? Re: 晶振波形异常 御社のFS32K144HFT0MLHT MCを使用しています 水晶発振器は8MHzの受動型水晶発振器(AV08000009)ですが、波形が異常です。この波形は貴社製MCUにとって許容範囲内でしょうか?また、正常な動作に影響はありますか? Re: S32K148有secureboot功能,但是bootloader在jtag关闭后起不来 こんにちは@vurtual 一般的な方法は、デバッグインターフェースを製造時に無効にすることであり、アプリケーションから後から無効化するのではなく、その場合、このプロセスは単一の生産ステップで完了します:フラッシュ構成フィールド(FCF)を再プログラムしてデバッグポートを無効化し、正しいBOOT_MAC値をプロビジョニングするか(または次のリセット後にCSEcが自動的に計算できるようにします)。 製品ライフサイクルの後半でデバッグインターフェースを無効化する必要がある場合も可能です。しかし、FCFが再プログラムされると、セキュアブートの計算には変更されたFCFの内容が含まれるため、BOOT_MACも更新する必要があります。そうしないと、セキュアブートの検証が失敗します。 BOOT_MACは標準的なSHEメモリ更新プロトコルを用いて更新可能で、CSEcキーの更新と同じ方法で行えます。BOOT_MACを新しいFCFの内容に合わせて更新した後、デバッグポートを無効にした状態でセキュアブートが正しく動作するはずです。 よろしくお願いいたします。 ルーカス Re: 晶振波形异常 この件のために新しいThreadを作成してください。ありがとう。 Re: 晶振波形异常 こんにちは、@ ルカシャドラパ 弊社では、貴社製FS32K144HFT0MLHTマイコンを8MHzのパッシブ水晶発振器(AV08000009)と組み合わせて使用していますが、波形が異常です。この水晶発振器の波形は貴社製マイコンにとって許容範囲内でしょうか?また、マイコンの正常な動作に影響はありますか?よろしくお願いいたします。 Re: S32K148有secureboot功能,但是bootloader在jtag关闭后起不来 こんにちは@vurtual これが不可逆的な操作であると、あなたはどこにお考えですか?それは正しくありません。BOOT_MAC更新可能です。 以前にも述べたように: 「BOOT_MACは標準的なSHEメモリ更新プロトコルで更新できます。CSEcキーの更新と同じ方法です。」 つまり、通常のSHE/CSEcキーのインポートや更新に使われるCMD_LOAD_KEYコマンドを使えます。 BOOT_MACを更新するには、標準のSHEキー更新手順に従ってM1~M5の値を生成する必要があります。キーカウンターは増分されなければならず、更新はMASTER_ECU_KEYまたはBOOT_MAC_KEYのいずれかで承認できます。 したがって、BOOT_MACの更新はサポートされている操作であり、元に戻せない操作ではありません。 よろしくお願いいたします。 ルーカス Re: 晶振波形异常 はい、ありがとうございます。
View full article
PCF8563TSのライフサイクル状況と長期的な供給状況 こんにちは.... 現在、 PCF8563TS RTCを製品の一つに使用しており、その長期的なライフサイクル状況をよりよく理解したいと考えています。 過去には、私たちの製品は PCF8563BSをベースにしており、最終的にはエンド・オブ・ライフ(EOL)に達しました。その結果、別のパッケージへの移行のためにハードウェアの全面的な再設計を行い、追加のエンジニアリング作業、検証、製造コストが発生しました。 こうした過去の経験を踏まえ、私たちは以下の点について質問したいと思います。 PCF8563TSがEOL(販売終了)またはNRND(新製品化)に近づいている兆候はありますか? このデバイスの長期的な供給計画はありますか? NXPは今後の製品ライフサイクルやロードマップについて何かCAN情報を共有できますか? PCF8563TSで新製品をデザインするお客様におすすめはありますか? 今後の計画は変更される可能性があることは理解していますが、この装置の期待される寿命に関する指針があれば、デザイン上の判断を下し、将来の再設計リスクを減らすのに役立ちます。 再開まで今しばらくお待ちください。 Re: PCF8563TS Lifecycle Status and Long-Term Availability 調べてみたところ、PCF8563TS $0.5のように在庫が多いチップでは、生産を止めるのは簡単ではありません。 Re: PCF8563TS Lifecycle Status and Long-Term Availability こんにちは、ビクターさん。 NXPセミコンダクターズの製品にご関心をお寄せいただき、またサポートの機会をいただきありがとうございます。 今後10〜15年間安定した供給を保証する長寿命プログラムの製品もあります。 長寿プログラム しかしPCF8563TSは長寿プログラムには含まれておらず、販売終了の通知や最終購入日はありません。お客様の要望次第です 敬具 アロンドラ 技術サポート NXPセミコンダクターズ
View full article
I.MX6 VPUエンコーディング機能 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> カメラ画像ストリームからH.264へのエンコードを行うためのi.mx6 VPUの評価を行っています。 私はi.MX6でのストリームエンコーディングは全くの初心者なので、センサの選択に惹かれました。私はその点に関して少し疑問を持っています。 1. VPUがH.264エンコーディングでサポートする最大解像度はどれくらいですか? 2. H.264エンコーディングにおいて、最大解像度でサポートされる最大フレームレートはどれくらいですか? 3. VPUがH.264エンコーディングでサポートする入力カラースペースは何ですか? 4. 例えば640×480ピクセルの解像度が低い場合、H.264エンコードで1920×1080ピクセルと比べてより高いフレームレートを得られるのでしょうか? 5. フレームレートはビットレートによって制限されますか? 6.IPUからVPUへストリームをルーティングしてエンコードすることは可能ですか? ありがとうございます グナ グラフィックスとディスプレイ i.MX6Quad Linux マルチメディア Yocto Project Re: I.MX6 VPU Encoding Features こんにちは、アルトゥール 1920x1080 30FPSの動画をデコードしながら、同時に1920x1080 30FPSの動画をエンコードすることは可能ですか?また、この情報が真実であるかどうかについて、文書に明記されていないのでしょうか? Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本当にありがとうございます Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 1.ホリソント解像度は1080ピクセルに制限されていますが、MJPEGのBPプロファイルでは最大8192x8192ピクセルまで画質が設定可能です。 2. ピクセル/秒と動作周波数の直接的な仕様はありません。さらに、VPUのスループットはエンコード処理とデコード処理で異なる。1つの1920x1080@30fpsストリームをエンコードし、1つの1920x1080@30fpsストリームと1つのD1@30fpsストリームをデコードすることができます。 アルトゥール Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> アルトゥール・ペトゥホフ、 ご回答ありがとうございます。 念のため確認ですが、VPUで1600 x 1200(UXGA)h264エンコーディングが@ 352Mhzでもできないということですか? VPUの動作周波数におけるスループットの計算方法は?266MHz動作時のスループットは約72,576,000ピクセル/秒だと読みました。これについて手伝ってもらえますか? Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Q1.VPUがH.264エンコードでサポートする最大解像度はどれくらいですか? Q2.H.264エンコーディングにおいて、最大解像度でサポートされる最大フレームレートはどれくらいですか? A1-2。i.MX6シリーズプロセッサのビデオ処理ユニット(VPU)は 最大1920x1080@30fpsの解像度/フレームレートでビデオストリームをエンコード/デコードします。 Q3.H.264エンコーディングにおいて、VPUがサポートする入力カラースペースは何ですか? A3. サポートされている入力カラースペースは、MJPEG コーデックを除き YUV4:2:0 です。 4:2:0、4:2:2、2:2:4、4:4:4、4:0:0をサポートしています。 Q4.例えば640×480ピクセルの解像度が低い場合、H.264エンコードで1920×1080ピクセルと比べてより高いフレームレートを得られるのでしょうか? A4. はい。 Q5.フレームレートはビットレートによって制限されますか? A5. エンコードされたビデオストリームのビットレートのことでしょうか?もしそうなら、答えはこうです:フレームレートとビットレートの間に直接的な関係はなく、結果となるビットレートは主に使用されるコーデックとエンコードプロファイルに依存します。 Q6.IPUからVPUへストリームをルーティングしてエンコードすることは可能ですか? A6. はい、システムメモリ内のフレームバッファを使用すれば可能です。例えば、IPUはカメラでキャプチャしたフレームをダブルバッファ方式を用いてシステムメモリに保存し、その後VPUがそこからフレームを取り出してエンコードする。 すてきな一日を、 アルトゥール ----------------------------------------------------------------------------------------------------------------------- 注:この記事があなたの質問への回答になっている場合は、「正解」ボタンをクリックしてください。ありがとう! ----------------------------------------------------------------------------------------------------------------------- Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ありがとう。私はそれを使って遊び始めました。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 答えは教えられない。 http://www.chipsnmedia.com/ に連絡してみて。 調べた参考文献も答えは出ていません。 http://www.chipsnmedia.com/data/goodsImages/1289972906&&CNM_Brochure_CODA960.pdf https://community.nxp.com/external-link.jspa?url=http %3A% 2F %2Fwww.chipsnmedia.com% 2Fsupport %2Fdown% 2Fcnm-codadx6-datashe… 船内で試してみることをおすすめします。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 杜武、 もしそうなら、640 x 480 @ 90fpsで実現することは可能でしょうか? ありがとうございます グナ Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> #1 最大ビットレートや最大クロック周波数は気にしません。 h264エンコードの場合、 1920*1080*30以下の通常の「幅*高さ*フレームレート」であれば問題ないと思います。 #2 i.MX プラットフォームにはDMAやキャッシュの整合性を扱う「物理メモリ 割り当てAPI」が必要です。 「IPU出力」と「VPU入力」が同じメモリと画像フォーマットを共有している場合、コピーや変換は不要です。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 杜武、 ご返信ありがとうございます。 いくつか疑問があります。 1.4と5については、 制限が幅×高さ×fpsの場合、VPUがサポートする最大ビットレートはどれくらいですか?ドキュメントには記載されていませんでした。私の知る限り、VPUの動作速度は最大352MHzまで上がることがあります。 2. 6の場合、 SDMAはこれに使えますか?はいの場合、何か制限事項はありますか? ありがとうございます グナ Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 略して: #1,2 1920x1080@30fps #3 YUV422(NV12)、YUV420 #4,5 制限値は「幅×高さ×フレームレート」だと思います。 #6 フォーマット変換かmemcpyが必要になるかもしれません。 詳細は以下をご覧ください。 http://www.nxp.com/webapp/Download?colCode=L4.1.15_1.1.0_LINUX_DOCS&Parent_nodeId=1337699481071706174845&Parent_pageType…
View full article
Config Tools for i.MX Config Tools for i.MX 26.06  in this tool i.mx952 not working also 95 , error : cannot download the processor database. Re: Config Tools for i.MX Hi @onkarbhalerao, Thank you for contacting NXP Support. I have tested this on my side and did not observe any issues. Could you please double check your internet connection and try again? If the issue persists, you can manually download the required files using the MCUXpresso SDK Builder Best regards, Chavira
View full article
I.MX6 VPU Encoding Features We are evaluating i.mx6 VPU for encoding to H.264 from camera image stream. As I am totally new to stream encoding in i.MX6, I am struck in choosing sensor. I am I have some doubts on that front. 1. What is the maximum resolution supported by VPU for H.264 encoding? 2. What is the maximum frame rate supported at maximum resolution for H.264 encoding? 3. What are input color space supported by VPU for H.264 encoding? 4. If you have less resolution say 640*480 pixels, can we get more frame rate compared to 1920*1080 pixels for H.264 encoding? 5. Is frame rate is limited by bit rate? 6. Is it possible to route stream from IPU to VPU for encoding? Thanks, Guna Graphics & Display i.MX6Quad Linux Multimedia Yocto Project Re: I.MX6 VPU Encoding Features Hi Artur is it possible to encode 1920x1080 30 FPS video while 1920x1080 30FPs video is decoded? Also no document specify this information if its true? Re: I.MX6 VPU Encoding Features Thank you so much Re: I.MX6 VPU Encoding Features 1. The horisontal resolution is limited to 1080 pixels except of the MJPEG BP profile where the maximum picture size can be up to 8192x8192 pixels. 2. There is no direct pixels/s vs operating frequency specification. Moreover, the VPU throughput is different for encoding and decoding operations. It can encode one 1920x1080@30fps stream and decode one 1920x1080@30fps stream plus one D1@30fps stream. Artur Re: I.MX6 VPU Encoding Features Artur Petukhov, Thank you for the response. Just to clarify, Does it mean that I cannot do 1600 x 1200 (UXGA) h264 encoding with VPU even if it runs @ 352Mhz? How to calculate the throughput for VPU operating frequency?. I read for 266Mhz operating the throughput is around 72,576,000 pixels/s. Can you help me on this? Re: I.MX6 VPU Encoding Features Q1. What is the maximum resolution supported by VPU for H.264 encoding? Q2. What is the maximum frame rate supported at maximum resolution for H.264 encoding? A1-2. The Video Processing Unit (VPU) of i.MX6 series processors can encode/decode a video streams at up to 1920x1080@30fps resolution/frame rate. Q3. What are input color space supported by VPU for H.264 encoding? A3. Supported input color space is YUV4:2:0 except of the MJPEG codec that supports 4:2:0, 4:2:2, 2:2:4, 4:4:4 and 4:0:0. Q4. If you have less resolution say 640*480 pixels, can we get more frame rate compared to 1920*1080 pixels for H.264 encoding? A4. Yes. Q5. Is frame rate is limited by bit rate? A5. Do you mean the bit rate of encoded video stream? If so, the answer is: there is no direct relation between frame rate and bit rate, the resulting bit rate mostly depends on the codec and encoding profile used. Q6. Is it possible to route stream from IPU to VPU for encoding? A6. Yes, it is possible using the frame buffer in system memory. For example, IPU stores the frames, captured by camera, to system memory using the double-buffer scheme, then VPU takes the frames to encode from there. Have a great day, Artur ----------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the Correct Answer button. Thank you! ----------------------------------------------------------------------------------------------------------------------- Re: I.MX6 VPU Encoding Features Thank you. I am started playing with that. Re: I.MX6 VPU Encoding Features I can't give you the answer, you can contact the http://www.chipsnmedia.com/. All the reference I searched can't answer it either. http://www.chipsnmedia.com/data/goodsImages/1289972906&&CNM_Brochure_CODA960.pdf https://community.nxp.com/external-link.jspa?url=http%3A%2F%2Fwww.chipsnmedia.com%2Fsupport%2Fdown%2Fcnm-codadx6-datashe… I suggest you try it on board. Re: I.MX6 VPU Encoding Features Du wu, If that's the case, then is it possible to do 640 x 480 @ 90 fps? Thanks, Guna Re: I.MX6 VPU Encoding Features #1 I don't care the maximum bitrate or maximum clock freq, I just think any regular "width*height*fps" under "1920*1080*30" will be ok for h264 encoding. #2 The i.MX platform must have "physical memory allocator api" which handle DMA and cache coherent. If "IPU output" and "VPU input" share the same memory and the same image format, no copy or convertion is required. Re: I.MX6 VPU Encoding Features Du wu, Thank you for the reply. I have some doubts, 1. For 4 &5,       If the limit is width * height * fps, then what is the maximum bit rate supported by VPU?.I cound not find that in their doc. As far as I know, the speed of operation of VPU can go up to 352Mhz. 2. For 6,         Can SDMA be used for this? If Yes, Is there any limitation with that? Thanks, Guna Re: I.MX6 VPU Encoding Features for short: #1,2 1920x1080@30fps #3 YUV422(NV12), YUV420 #4,5 i think the limit is "width*height*fps". #6 i think you may need format convertion or memcpy. for detail: http://www.nxp.com/webapp/Download?colCode=L4.1.15_1.1.0_LINUX_DOCS&Parent_nodeId=1337699481071706174845&Parent_pageType…
View full article
S32K358 + FreeRTOS: PendSV_Handler実行中にランダムなハードフォルトが発生 チームの皆さん、こんにちは。 FreeRTOSを実行しているS32K358で、ランダムなハードフォルトが発生しています。 アプリケーションは長時間正常に動作しますが、突然フリーズします。システムが実行を停止した後、ソフトウェア・ウォッチドッグ(SWT)はサービスされず、最終的にコントローラがリセットされます。 障害は即座に発生するわけではなく、約1~2時間の連続実行後に発生する。 障害発生後に停止すると、コールスタックには以下が表示されます。 PenSV_Handler() ↓ HardFault_Handler() レジスタ値: LR = 0xA5A5A5A5 PC = 0x00407BD9 LR = 0xA5A5A5A5は、有効な戻りアドレスというよりは、メモリ初期化パターンのように見えます。 その他の登録簿: R0 = 0x204011A8 R3 = 0x2040012C R12 = 0x20400010 ご提案やデバッグに関するアドバイスなど、何でもいただければ大変ありがたいです。 Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler こんにちは、 @nirmal_masilamani さん。 FreeRTOSのコンテキスト切り替え時に保存されたタスクコンテキストが破損しているようです。 PendSVはFreeRTOSによってコンテキスト切り替えに使用されるため、PendSV_Handler()内でHardFaultが発生した場合、多くの場合、スケジューラが無効なタスクコンテキストを復元しようとしていることを意味します。 考えられる根本原因の一つは、タスクスタックオーバーフローです。タスクのスタックサイズを増やし、FreeRTOSのスタックオーバーフロー検出機能を有効にすることをお勧めします。 configCHECK_FOR_STACK_OVERFLOW 実装: vApplicationStackOverflowHook()。 さらに、uxTaskGetStackHighWaterMark()を使って各タスクの残りのスタック空間を定期的に監視することもできます。これにより、故障が発生する前にスタック限界に近いタスクを特定するのに役立ちます。 よろしくお願いいたします。 ダニエル Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler こんにちは、 @danielmartynek さん、 ご回答ありがとうございます。 既にスタックサイズを増やしたり、スタックオーバーフローフックを有効にしたりしてみました。 Overflow Hookにdebug CAN msgを追加しましたが、故障発生時にそのメッセージが届きません。 また、障害が発生した際には uxTaskGetStackHighWaterMark()を監視します。 タスク 1 : 1977 × 4 ≈ 7908 バイトの空き容量 タスク2:1971 × 4 ≈ 7884バイトの空き容量 タスク3:3988 × 4 ≈ 15952バイトの空き容量 Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler こんにちは、 @nirmal_masilamani さん。 したがって、根本原因としてスタックオーバーフローを除外できるでしょう。 しかし、タスクコンテキストは依然として破損している。プロセッサはLR = 0xA5A5A5A5を復元しており、これがUsageFaultを引き起こします。0xA5A5A5A5 は tskSTACK_FILL_BYTE (0xA5U) から生成されるパターンで、FreeRTOS がタスクスタックを作成する際にタスクスタックを埋めるために使用されます。 したがって、LRが0xA5A5A5A5になった場合、コンテキストは有効なレジスタ値ではなく、元のスタックフィルパターンが残っている場所から復元されます。 SPが破損した場合に起こり得ます。その場合、PendSV_Handler()はRAM内の誤った場所からタスクコンテキストを復元します。 スタックポインタのアドレスからSRAM領域を特定できるはずです。 MPUとXRDCを使用して、その領域を適切に保護することをお勧めします。 また、FreeRTOS APIを呼び出す割り込み処理はありますか?もしそうなら、FromISR()のバリアントを使っているのか、configMAX_SYSCALL_INTERRUPT_PRIORITYに関して優先順位は正しく設定されているのか? よろしくお願いいたします。 ダニエル
View full article
S32K358 SWAP ABのMCAL-XDRC構成 以下の3つの質問に答えるのを手伝ってください。 1. 現在、SWAP機能を使用する必要があります。RMモジュール内のXDRCメモリ構成において、フラッシュBブロック:0x800000-0xbffffffを定義する必要はありますか? 2. HSEが占有しているフラッシュメモリ領域0x7D4000-0x7FFFFFをメモリ構成から削除する必要がありますか? 3. core0をOSを実行するプライマリコア、core2をアルゴリズムを実行するセカンダリコアと定義します。次に、Domain_Assgnment_0にCM7_0、CM7_1、GMAC、uSDHC、eDMAを割り当て、Domain_Assgnment_1にCM7_2を割り当てました。これは正しいでしょうか?実際のアプリケーションでは、使用されていないマスターコアを構成から省略できますか? Re: S32K358 SWAP AB的MCAL-XDRC配置 こんにちは、@scott071209 1.アプリケーションまたはブートローダーは、パッシブパーティション内の画像の詳細を消去、プログラム、検証、読み込みを行う必要があります。つまり、パッシブパーティションもXRDCでカバーされる必要があるということだ。 2. AB_SWAPファームウェアの場合、XRDCはリセット時に自動的に設定され、HSE FWアクティブフラッシュエリア、HSE FWパッシブフラッシュエリア、HSE FWデータフラッシュ、HSE UTESTエリアを保護します。この目的にはディスクリプタ12〜15が使われ、この構成はロックされているため、ユーザーが変更することはできません。詳細はHSEファームウェアのリファレンスマニュアルのセクションで確認できます: “14.6.3.3デフォルトのMRC 0構成(AB_SWAP)」 したがって、HSE資源を自社のXRDC構成でカバーする必要はありません。 3. はい、そのようなセットアップを利用できます。マスターが使われていない場合は、設定で省略できます。 ただし、HSEを使用する場合は、ドメイン3もHSE用に構成する必要があります。これはHSEリソースを保護するためではなく、HSEにユーザーデータへのアクセス権を与え、暗号操作を行うためのものです。 S32K358には4つのドメインがあり、HSEは常に利用可能な最高位のドメインに割り当てられます。S32K358の場合はドメイン3です。これは固定されているので、変更できません。RTDの新しいバージョンでは、HSEマスターはXRDC構成でリストにすら含まれていません。なぜなら再構成ができないからです。ドメイン3にHSEのみを配置したい場合は、このドメインにマスターを割り当てる必要はありません。HSE(健康・安全・環境)は既に自動的に組み込まれています。 以前のRTDバージョンでは、HSEを他のドメインに割り当てることが可能でしたが、そのような設定は効果がありませんでした。そのため、削除されました。 よろしくお願いいたします。 ルーカス
View full article
面向 i.MX 的配置工具 此工具中的 i.MX 26.06 配置工具 i.mx952 也无法工作,错误为:无法下载处理器数据库。 Re: Config Tools for i.MX 你好@onkarbhalerao , 感谢您联系恩智浦技术支持。 我这边已经测试过了,没有发现任何问题。 请您检查一下网络连接,然后重试。 如果问题仍然存在,您可以使用MCUXpresso SDK Builder手动下载所需文件。 此致, 查维拉
View full article
MCAL-XDRC Configuration of S32K358 SWAP AB Please help me answer these three questions: 1. I currently need to use the SWAP function. In the XDRC memory configuration within the RM module, do I still need to define the flash B-block: 0x800000-0xbfffff? 2. Does the flash space 0x7D4000-0x7FFFFF occupied by HSE need to be deleted from the memory configuration? 3. I define core0 as the primary core, running the OS, and core2 as the secondary core, running algorithms. Then, I allocated CM7_0, CM7_1, GMAC, uSDHC, and eDMA in Domain_Assgnment_0; and allocated CM7_2 in Domain_Assgnment_1. Is this correct? In practical applications, can the unused master core be omitted from the configuration? Re: S32K358 SWAP AB的MCAL-XDRC配置 Hi @scott071209  1. The application or bootloader will need to: erase, program, validate and read details about the image in passive partition. That means passive partition should be also covered by XRDC. 2. In case of AB_SWAP firmware, XRDC is automatically configured during reset to protect HSE FW active flash area, HSE FW passive flash area, HSE FW data flash and HSE UTEST area. Descriptors 12-15 are used for this purpose and this configuration is locked, so it can’t be modified by user. Details can be found in HSE Firmware reference manual in section: “14.6.3.3 Default MRC 0 configuration (AB_SWAP)” So, you don’t need to cover HSE resources by your own XRDC configuration. 3. Yes, you can use such setup. If a master is not used, you can omit it in the configuration. But if you use HSE, you will need to configure also domain 3 for HSE. This is not to protect HSE resources, this is to give access rights to HSE to access user data to be able to perform cryptographic operation. S32K358 has four domain and HSE is always assigned to highest available domain. In case of S32K358, it’s domain 3. It’s hardwired, this cannot be changed. In newer version of RTD, HSE master is not even available in the list in XRDC configuration because it can’t be reconfigured. If you want to have only HSE in domain 3, you do not need to assign any master to this domain. HSE is already there automatically. In older RTD versions, it was possible to assign HSE to other domains but such configuration had no effect. Therefore it was removed. Regards, Lukas
View full article
S32K358 + FreeRTOS: Random HardFault during PendSV_Handler Hi Team, I am facing a random HardFault issue on an S32K358 running FreeRTOS. The application runs normally for a long duration and then suddenly hangs. After the system stops executing, the Software Watchdog (SWT) is not serviced and eventually resets the controller. The failure is not immediate—it occurs after approximately 1 to 2 hours of continuous execution When halted after the failure, the call stack shows: PendSV_Handler() ↓ HardFault_Handler() Register values: LR = 0xA5A5A5A5 PC = 0x00407BD9 LR = 0xA5A5A5A5 looks like a memory initialization pattern rather than a valid return address. Other registers: R0 = 0x204011A8 R3 = 0x2040012C R12 = 0x20400010 Any suggestions or debugging recommendations would be greatly appreciated. Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler Hi @nirmal_masilamani, It looks like the task context saved during the FreeRTOS context switch has been corrupted. PendSV is used by FreeRTOS for context switching, therefore, if the HardFault occurs inside PendSV_Handler(), it often means the scheduler is attempting to restore an invalid task context. One possible root cause is a task stack overflow. I would recommend increasing the stack size of the tasks and enabling FreeRTOS stack overflow detection: configCHECK_FOR_STACK_OVERFLOW Implement: vApplicationStackOverflowHook(). Additionally, you can periodically monitor the remaining stack space of each task using uxTaskGetStackHighWaterMark(). This can help identify tasks that are running close to their stack limits before the fault occurs. Regards, Daniel Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler Hello @danielmartynek , Thank you for response, I already tried increased stack size, enabled stack overflow hook. Added debug CAN msg in overflow hook, I am not receiving that message when fault occur. Also monitoring uxTaskGetStackHighWaterMark(), when fault occur Task 1 : 1977 × 4 ≈ 7908 bytes free Task 2: 1971 × 4 ≈ 7884 bytes free Task 3: 3988 × 4 ≈ 15952 bytes free Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler Hi @nirmal_masilamani, So we can probably exclude a stack overflow as the root cause. However, the task context is still getting corrupted. The processor is restoring LR = 0xA5A5A5A5, which results in a UsageFault. 0xA5A5A5A5 is the pattern generated from tskSTACK_FILL_BYTE (0xA5U) and is used by FreeRTOS to fill task stacks when they are created. Therefore, if LR becomes 0xA5A5A5A5, the context is restored from a location that still contains the original stack fill pattern rather than a valid register value. This could happen if the SP gets corrupted. In that case, PendSV_Handler() would restore the task context from a wrong location in RAM. You should be able to identify the SRAM region from the stack pointer address.  I would recommend that you properly protect the region by MPUs and XRDC.  Also, are any interrupts calling FreeRTOS APIs? If so, are they using the FromISR() variants, and are their priorities configured correctly with respect to configMAX_SYSCALL_INTERRUPT_PRIORITY? Regards, Daniel
View full article
i.MX用設定ツール このツールの i.MX 26.06 設定ツール i.mx952 も動作しません。エラー:プロセッサデータベースをダウンロードできません。 Re: Config Tools for i.MX こんにちは、 @onkarbhalerao さん。 NXPサポートまでご連絡いただきありがとうございます。 こちら側でテストしてみましたが、特に問題は確認されませんでした。 インターネット接続をもう一度確認して、もう一度お試しいただけますか? 問題が続く場合は、MCUXpresso SDK Builderを使って必要なファイルを手動でダウンロードできます よろしくお願いします、 チャビラ
View full article
I.MX6 VPU 编码特性 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我们正在评估 i.mx6 VPU 对从摄像头图像流编码为 H.264 的性能。 由于我对 i.MX6 的流媒体编码完全不熟悉,所以在选择传感器时遇到了困难。我对此有些疑问。 1. VPU 对 H.264 编码支持的最大分辨率是多少? 2. H.264 编码在最高分辨率下支持的最大帧速率是多少? 3. VPU 支持的 H.264 编码输入色彩空间有哪些? 4. 如果分辨率较低,例如 640*480 像素,与 1920*1080 像素相比,H.264 编码能否获得更高的帧速率? 5. 帧速率是否受比特率限制? 6.是否可以将流从IPU路由到VPU进行编码? 谢谢! 古纳 图形与显示 i.MX6 四核 Linux 多媒体 Yocto Project Re: I.MX6 VPU Encoding Features 你好,Artur 是否可以在解码 1920x1080 30FPS 视频的同时,对 1920x1080 30FPS 视频进行编码?此外,也没有任何文件说明此信息是否属实? Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 太感谢了 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 1.水平分辨率限制为 1080 像素,但 MJPEG BP 配置文件的最大图像尺寸可达 8192x8192 像素。 2. 没有直接的像素/秒与工作频率的关系规范。此外,VPU 的吞吐量对于编码和解码操作是不同的。它可以编码一个 1920x1080@30fps 流,并解码一个 1920x1080@30fps 流和一个 D1@30fps 流。 阿图尔 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 阿图尔·佩图霍夫 谢谢你的回复。 为了澄清一下,这是否意味着即使 VPU 运行频率为 352MHz,我也无法使用 VPU 进行 1600 x 1200 (UXGA) h264 编码? 如何计算VPU工作频率下的吞吐量?我查阅资料得知,266MHz 运行频率下的吞吐量约为72,576,000像素/秒。你能帮我解决这个问题吗? Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Q1.VPU对H.264编码支持的最大分辨率是多少? Q2.H.264编码在最高分辨率下支持的最大帧速率是多少? A1-2。i.MX6系列处理器的视频处理单元(VPU)可以 以最高 1920x1080@30fps 分辨率/帧速率对视频流进行编码/解码。 Q3.VPU支持的H.264编码输入色彩空间有哪些? A3. 支持的输入色彩空间为 YUV4:2:0,但 MJPEG 编解码器除外。 支持 4:2:0、4:2:2、2:2:4、4:4:4 和 4:0:0。 第四季度。如果分辨率较低,例如 640*480 像素,与 1920*1080 像素相比,使用 H.264 编码能否获得更高的帧速率? A4。是的。 Q5.帧速率是否受比特率限制? A5. 您指的是编码视频流的比特率吗?如果真是这样,答案是:帧速率和比特率之间没有直接关系,最终的比特率主要取决于所使用的编解码器和编码配置文件。 Q6.是否可以将流从IPU路由到VPU进行编码? A6. 是的,可以使用系统内存中的帧缓冲区。例如,IPU 使用双缓冲方案将摄像头捕获的帧存储到系统内存中,然后 VPU 从那里获取帧进行编码。 祝你有美好的一天, 阿图尔 ----------------------------------------------------------------------------------------------------------------------- 注:如果此回复解答了您的问题,请点击“正确答案”按钮。谢谢你! ----------------------------------------------------------------------------------------------------------------------- Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 谢谢。我开始玩那个了。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我无法给你答案,你可以联系http://www.chipsnmedia.com/ 。 我查阅的所有资料都无法解答这个问题。 http://www.chipsnmedia.com/data/goodsImages/1289972906&&CNM_Brochure_CODA960.pdf https://community.nxp.com/external-link.jspa?url=http %3A% 2F %2Fwww.chipsnmedia.com% 2Fsupport %2Fdown% 2Fcnm-codadx6-datashe… 我建议你在船上试试。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 杜武, 如果真是这样,那么有可能实现 640 x 480 @ 90 fps 的分辨率吗? 谢谢! 古纳 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> #1 我不在乎最大比特率或最大时钟频率。 我认为任何小于“1920*1080*30”的常规“宽度*高度*帧率”都适合h264编码。 #2 i.MX 平台必须具有“物理内存分配器 API”,该 API 可处理 DMA 和缓存一致性。 如果“IPU 输出”和“VPU 输入”共享同一内存和同一图像格式,则无需复制或转换。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 杜武, 感谢您的回复。 我有些疑问。 1.对于 4 和 5, 如果限制条件是宽度*高度*帧率,那么VPU支持的最大比特率是多少?我在他们的文档中找不到相关信息。据我所知,VPU 的运行速度最高可达 352MHz。 2. 对于 6, SDMA 可以用于此吗?如果答案是肯定的,那么这样做有什么限制吗? 谢谢! 古纳 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 简称: #1,2 1920x1080@30fps #3 YUV422(NV12)、YUV420 #4,5 我认为限制条件是“宽度*高度*帧率”。 # 6 我认为你可能需要进行格式转换或使用 memcpy 命令。 详情如下: http://www.nxp.com/webapp/Download?colCode=L4.1.15_1.1.0_LINUX_DOCS&Parent_nodeId=1337699481071706174845&Parent_pageType…
View full article
Python で ReadPipeUIntArray を使用するとセグメンテーション違反が発生します こんにちは、 現在、パイプを使用してターゲットからホストへデータパケット(ヘッダー+ペイロード)をストリーミングしようとしていますが、問題が発生しています。 ReadPipeUIntArrayを使用してバイナリデータを読み込む際に、fmliteが頻繁にクラッシュします。参考として、Pythonのサンプルコードとfmliteの出力結果を添付しました。 前もって感謝します Re: Segmentation fault when using ReadPipeUIntArray via Python こんにちは、 @tschue-nxt さん。 現在この問題について調査中です。進展があり次第、ご連絡いたします。 Re: Segmentation fault when using ReadPipeUIntArray via Python こんにちは、@tschue-nxt さん。 添付のFMLITEバイナリを確認して、あなたのケースで動作するか教えてもらえますか? Re: Segmentation fault when using ReadPipeUIntArray via Python こんにちは、 @iulian_stan さん。 見た目も良く、ここ数分間はスムーズに動作しています。迅速な対応ありがとうございました!
View full article
S32K358 SWAP AB的MCAL-XDRC配置 有3个问题请帮忙解答一下: 1. 目前我需要使用SWAP功能。在RM模块里的XDRC的memory congfig中还需要对flash B-block:0x800000-0xbfffff进行定义吗? 2. HSE占用的flash空间0x7D4000-0x7FFFFF需要在memory congfig里删除吗? 3. 我把core0定义为主核,跑OS。把core2定义为副核,跑算法。那么我在Domain_Assgnment_0里分配了CM7_0,CM7_1,GMAC,uSDHC,eDMA内容;在Domain_Assgnment_1中分配了CM7_2;这样对吗?实际应用中没有使用的master是不是可以不用出现在配置里? Re: S32K358 SWAP AB的MCAL-XDRC配置 嗨@scott071209 1.应用程序或引导加载程序需要:擦除、编程、验证和读取被动分区中映像的详细信息。这意味着被动分区也应该由 XRDC 覆盖。 2. 对于 AB_SWAP 固件,RESET 期间会自动配置 XRDC,以保护 HSE FW 活动闪存区域、HSE FW 无源闪存区域、HSE FW 数据闪存和 HSE UTEST 区域。描述符 12-15 用于此目的,并且此配置已锁定,因此用户无法修改。详细信息请参阅 HSE 固件参考手册的以下章节: “14.6.3.3默认 MRC 0 配置 (AB_SWAP)” 因此,您无需通过自己的 XRDC 配置来涵盖 HSE 资源。 3. 是的,您可以使用这样的设置。如果未使用主服务器,则可以在配置中省略它。 但是,如果您使用 HSE,则还需要为 HSE 配置功能域 3。这不是为了保护 HSE 资源,而是为了赋予 HSE 访问用户数据的权限,以便能够执行加密操作。 S32K358 有四个功能域,HSE 总是被分配到最高可用功能域。以 S32K358 为例,它是功能域 3。这是硬编码的,无法更改。在新版本的 RTD 中,HSE 主站甚至不在 XRDC 配置的列表中,因为它无法重新配置。如果您只想在功能域 3 中拥有 HSE,则无需为此功能域分配任何主服务器。HSE(健康、安全和环境)功能已自动启用。 在较早的 RTD 版本中,可以将 HSE 分配给其他域,但这种配置没有任何效果。因此它被移除了。 问候, 卢卡斯
View full article
S32K358 + FreeRTOS:PendSV_Handler 期间出现随机硬故障 大家好, 我在运行 FreeRTOS 的S32K358上遇到了随机硬故障问题。 应用程序长时间正常运行后突然卡死。系统停止运行后,软件看门狗(SWT)得不到服务,最终导致控制器重置。 故障并非立即发生,而是在连续执行约1 至 2 小时后出现。 故障停止后,调用堆栈显示: PendSV_Handler() ↓ HardFault_Handler() 寄存器值: LR = 0xA5A5A5A5 PC = 0x00407BD9 LR = 0xA5A5A5A5看起来像是内存初始化模式,而不是有效的返回地址。 其他登记簿: R0 = 0x204011A8 R3 = 0x2040012C R12 = 0x20400010 任何建议或调试技巧都将不胜感激。 Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler 你好@nirmal_masilamani , 看起来在 FreeRTOS 上下文切换期间保存的任务上下文已损坏。 PendSV 被 FreeRTOS 用于上下文切换,因此,如果在 PendSV_Handler() 内部发生 HardFault,通常意味着调度程序正在尝试恢复无效的任务上下文。 一个可能的根本原因是任务堆栈溢出。我建议增加任务的堆栈大小并启用 FreeRTOS 堆栈溢出检测: configCHECK_FOR_STACK_OVERFLOW 实现: vApplicationStackOverflowHook()。 此外,您可以使用 uxTaskGetStackHighWaterMark() 定期监测每个任务的剩余堆栈空间。这有助于在故障发生之前识别出接近堆栈限制运行的任务。 此致, 丹尼尔 Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler 你好@danielmartynek , 感谢您的回复。 我已经尝试过增加堆栈大小,启用堆栈溢出钩子。 我在溢出钩子中添加了调试 CAN 消息,但发生故障时没有收到该消息。 同时监控uxTaskGetStackHighWaterMark(),当发生故障时 任务 1:1977 × 4 ≈ 7908 字节可用空间 任务 2:1971 × 4 ≈ 7884 字节可用空间 任务 3:3988 × 4 ≈ 15952 字节可用空间 Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler 你好@nirmal_masilamani , 因此,我们大概可以排除堆栈溢出是根本原因的可能性。 然而,任务上下文仍然会遭到破坏。处理器正在恢复 LR = 0xA5A5A5A5,这导致了 UsageFault。0xA5A5A5A5 是由 tskSTACK_FILL_BYTE (0xA5U) 生成的模式,FreeRTOS 使用该模式在创建任务堆栈时填充任务堆栈。 因此,如果 LR 变为 0xA5A5A5A5,则上下文将从仍然包含原始堆栈填充模式的位置恢复,而不是从有效的寄存器值恢复。 如果存储过程损坏,就可能发生这种情况。在这种情况下,PendSV_Handler() 会从 RAM 中的错误位置恢复任务上下文。 你应该能够根据堆栈指针地址识别出 SRAM 区域。 我建议您使用 MPU 和 XRDC 对该区域进行适当保护。 另外,是否有任何中断调用 FreeRTOS API?如果是这样,他们是否使用了 FromISR() 变体,并且他们的优先级是否根据 configMAX_SYSCALL_INTERRUPT_PRIORITY 正确配置? 此致, 丹尼尔
View full article
使用 Python 的 ReadPipeUIntArray 时出现段错误。 您好, 目前我遇到的问题是,我想使用管道将数据包(头部+有效载荷)从目标流式传输到主机。 使用 ReadPipeUIntArray 读取二进制数据时,我经常遇到 fmlite 崩溃的情况。我附上了一个 Python 示例和 fmlite 输出作为参考。 提前致谢 Re: Segmentation fault when using ReadPipeUIntArray via Python 嗨@tschue-nxt , 我们正在调查此事,一旦有最新进展,我们会立即通知您。 Re: Segmentation fault when using ReadPipeUIntArray via Python 嗨@tschue-nxt , 请您检查一下附件中的 fmlite 二进制文件,并与我们联系它是否能在您的设备上正常运行。 Re: Segmentation fault when using ReadPipeUIntArray via Python 嗨@iulian_stan , 看起来不错,已经流畅运行好几分钟了。感谢你们快速修复!
View full article
Segmentation fault when using ReadPipeUIntArray via Python Hi, I am running into issues currently where I want to use a pipe to stream data packets (header+payload) from target to host. When using ReadPipeUIntArray to read the binary data I am running into fmlite crashes frequently. I attached a python example and fmlite output as reference. Thanks in advance Re: Segmentation fault when using ReadPipeUIntArray via Python Hi @tschue-nxt, We are looking into this issue and will get back to you once we have an update. Re: Segmentation fault when using ReadPipeUIntArray via Python Hi @tschue-nxt, Could you check the attached fmlite binary and let us know if it works in your case. Re: Segmentation fault when using ReadPipeUIntArray via Python Hi @iulian_stan, looks good, working smoothly for quite some minutes now. Thanks for the fast fix!
View full article
Radar – Processing Chain – NXP Radar SDK 1 Table of Contents • Introduction • FMCW Radar Signal • The Radar Cube • Processing Chain Overview • Mapping the Processing Chain onto the S32R45 • Range FFT • Doppler FFT • Non-Coherent Combining • CFAR Detection • Clustering (DBSCAN) • Angle Estimation (MUSIC DoA) • NXP Radar SDK Integration • Tools and Ecosystem • Conclusion 2 Introduction In the previous articles of this series, we introduced the fundamentals of automotive radar in the Radar Overview and the hardware/software setup in Radar SW & HW Environment. Building on that foundation, this article follows the radar data on its journey through the complete processing chain — from digitized ADC samples to a final target list describing each object’s range, velocity, and angle. The chain is modeled and prototyped in MATLAB® using Radar Toolbox™ and deployed on the NXP S32R45 radar processor through the NXP Model-Based Design Toolbox for RADAR. The key processing stages are distributed across the S32R45 Cortex-A53 cores, the SPT accelerator, the BBE32 DSP accelerator, and the LAX accelerator, using optimized kernels from the NXP Radar SDK. 3 FMCW Radar Signal Frequency-Modulated Continuous Wave (FMCW) radar transmits a continuous chirp whose frequency increases linearly over time. The received echoes are mixed with the transmitted signal, producing a beat frequency (also called intermediate frequency, IF) proportional to the round-trip delay, which directly encodes target range. Figure 1: FMCW Radar Transmit and Receive Chirp Diagram The diagram plots frequency (vertical axis) against time (horizontal axis) and shows two piecewise-linear signals. The transmitted signal Tx (blue) rises linearly across the chirp, while the received signal Rx (orange) has the same shape but is delayed in time: Tx(t) = A Tx · cos( 2π f c t + 2π (f B / 2T) t² + φ 0 ) Rx(t) = A Rx · cos( 2π f c (t − t d ) + 2π (f B / 2T) (t − t d )² + φ 0 ) The relevant variables are summarized below: Symbol Meaning Tx(t) Transmitted signal (blue curve) Rx(t) Received signal (orange curve) t d Propagation delay between Tx and Rx IF Frequency difference between Tx and Rx during the chirp T Chirp (ramp) duration f c Chirp starting frequency f B Chirp bandwidth R 0 Range of detected target v Velocity of detected target The three key physical intuitions of FMCW radar are: Range comes from the beat frequency, since the propagation delay t d = 2(R 0 + v·t)/c produces a frequency offset IF = (2 f B )/(T·c) · R 0 during the linear ramp. Velocity comes from the phase evolution across successive chirps via the Doppler effect. A moving target introduces a Doppler frequency f v = (2 f c / c) · v. The chirps repeat at a fixed pulse repetition frequency (PRF), which must be high enough to capture this Doppler shift. Angle comes from the phase differences introduced across multiple receive antennas, enabling direction estimation and spatial separation of targets. Chirp parameters are chosen according to sensing requirements: the chirp duration must exceed the round-trip time to the farthest target plus the additional time needed for mixing and signal formation. 4 The Radar Cube After mixing and sampling, the acquired data is organized into a 3D structure called the radar cube, which is the input to the entire digital processing chain. For a single antenna, each chirp produces a sequence of time samples (fast time) arranged into a column — one column per chirp. Stacking chirps side by side forms a 2D matrix (samples × chirps), and repeating this for every receive antenna and stacking along a third dimension produces the cube: samples × chirps × antennas. Figure 2: The radar cube Every subsequent stage operates on this cube, progressively collapsing its dimensions and transforming raw echoes into higher-level target information. 5 Processing Chain Overview The FMCW processing chain converts the radar cube into a compact target list through a sequence of well-defined stages. Before looking at each block in detail, the table below provides a roadmap of the inputs and outputs at every step: Stage Input Output Range FFT Radar cube Range cube Doppler FFT Range cube Range–Doppler cube Non-Coherent Combining Range–Doppler cube Range–Doppler map CFAR Detection Range–Doppler map Detections DBSCAN Clustering Detections Target clusters MUSIC DoA Clusters + antenna data (range, velocity, angle) Figure 3: Processing Chain Overview The process begins at the ADC, where analog signals are digitized. Range and Doppler FFTs extract distance and velocity, forming a range–Doppler representation. Data from multiple antennas is then combined to improve robustness, CFAR detects potential targets using adaptive thresholding, DBSCAN groups detections into individual targets, and MUSIC DoA estimates each target’s angle — converting raw samples into structured outputs of range, velocity, and angle. 6 Mapping the Processing Chain onto the S32R45 A key advantage of the NXP platform is that each stage of the chain is mapped onto the most suitable compute resource of the S32R45. The FFT-based stages and Non-Coherent Combining run on the SPT accelerator, the CFAR detection runs on the BBE32 DSP, the clustering runs on the Cortex-A53 cores, and the linear-algebra-heavy MUSIC estimation is offloaded to the LAX accelerator: Figure 4: Radar processing chain hardware mapping This mapping is what allows developers to prototype the entire chain in MATLAB and then deploy each stage to dedicated radar hardware without leaving the Model-Based Design environment. 7 Range FFT The first stage operates on the radar cube by processing the fast-time samples within each chirp. For every antenna and chirp, the time-domain signal — containing superimposed beat frequencies from multiple targets — is transformed into the frequency domain using an FFT, separating the frequency components that each correspond to a distinct propagation delay, and therefore a specific range. In this application, the radar front end does not perform in-phase and quadrature (I/Q) demodulation, so the acquired signal is purely real-valued. The resulting FFT spectrum is therefore symmetric, carrying redundant positive and negative frequency components. Since only the positive frequencies correspond to physically meaningful beat frequencies here, the negative-frequency half of the spectrum is discarded. The radar cube is thus converted into a set of range profiles, where each sample index becomes a range bin. The output preserves the chirp and antenna dimensions but now contains complex values indexed by range — magnitudes indicating reflection strength, and phases retained for later processing. Figure 5: Range FFT output On the S32R45, this stage is executed on the SPT accelerator using the rangeFFT kernel provided by the NXP Radar SDK and exposed through the NXP Model-Based Design Toolbox for RADAR. 8 Doppler FFT Building on the range-transformed data, the second stage processes the slow-time dimension by examining how the complex samples evolve across consecutive chirps. For a given range bin, a moving target produces a small phase difference between the corresponding Range FFT outputs of consecutive chirps. This progressive phase shift is a manifestation of the Doppler effect and encodes the target’s radial velocity. By analyzing these phase variations over time using a second FFT, the processing chain extracts the Doppler frequency components associated with motion. This step converts the phase evolution observed across successive Range FFT outputs into velocity information, effectively mapping stationary and moving targets into different Doppler bins. The output is a set of range–Doppler maps, one per antenna, where each cell represents a specific combination of distance and radial velocity and holds a complex value describing the target echo. The Doppler FFT output is shifted (typically via an FFT-shift operation) so that the zero-Doppler component is centered and negative Doppler frequencies appear first, giving a more intuitive velocity axis: negative values for targets moving in one direction, positive for the other. Figure 6: Doppler FFT output As with the Range FFT, this stage is accelerated on the SPT accelerator through the Radar SDK dopplerFFT kernel. 9 Non-Coherent Combining At this point, each antenna provides its own range–Doppler map, differing mainly in phase due to the direction of arrival. These maps are combined across the antenna dimension, typically by computing magnitudes and aggregating them through averaging. The input is a set of complex-valued maps; the output is a single range–Doppler magnitude matrix in which the antenna dimension has been collapsed. This suppresses uncorrelated noise and reinforces consistent target reflections, producing a cleaner, more robust representation well suited for detection. Figure 7: Non-Coherent Combining output Note: the pre-combining per-antenna data is retained, because it is required later for MUSIC direction-of-arrival estimation. This stage corresponds to the Non-Coherent Combining kernel ( NonCohComb ) of the NXP Radar SDK, executed on the SPT accelerator. 10 CFAR Detection The combined range–Doppler magnitude matrix is then scanned to identify potential targets. Each cell is evaluated against a locally adaptive threshold derived from its surrounding neighborhood: nearby training cells estimate the noise level, while guard cells are excluded to avoid contaminating the estimate with the target’s own energy. Through this process, the continuous-valued matrix becomes a discrete set of detections — cells whose magnitude significantly exceeds the estimated noise background. These are effectively points in range–velocity space representing likely target reflections. CFAR runs on the BBE32 DSP accelerator. 11 Clustering (DBSCAN) CFAR detections often include several neighboring points from the same physical target, as well as isolated points caused by noise. To organize them, DBSCAN clustering is applied in the range–velocity domain, grouping points based on spatial density. Taking the detection coordinates as input, DBSCAN forms clusters where dense regions correspond to real targets, while sparse detections are discarded as noise. The output is a set of target clusters, each consolidating a single target’s range and velocity. This stage runs on the Cortex-A53 cores. 12 Angle Estimation (MUSIC DoA) For each cluster, the detections are traced back to the complex per-antenna data from the range–Doppler stage. These per-antenna samples form vectors encoding the phase differences related to the direction of arrival. Combining multiple detections within a cluster, a covariance matrix is estimated to capture the spatial characteristics of the received signals. An eigenvalue decomposition separates signal and noise subspaces, and criteria such as AIC determine the number of significant sources. The MUSIC algorithm then scans possible directions and identifies those that best match the signal subspace. MUSIC has important practical limitations: the number of detectable signals must be strictly smaller than the number of antennas, otherwise the covariance matrix cannot be properly decomposed. It is also sensitive to low signal-to-noise ratio, correlated reflections, and array calibration errors — constraining its use in scenarios with many closely spaced targets or too few antenna elements. On the S32R45, the MUSIC implementation is offloaded to the LAX accelerator through the NXP Model-Based Design Toolbox for RADAR, demonstrating how computationally intensive linear-algebra operations can be accelerated directly from MATLAB-generated code. The result is a direction-of-arrival estimate for each clustered target, completing its spatial characterization. 13 NXP Radar SDK Integration The NXP S32R45 Radar SDK (RSDK 1.2.0) provides optimized radar processing kernels designed for the S32R45 radar processor. Through the NXP Model-Based Design Toolbox for RADAR, these kernels are callable directly from MATLAB and are automatically integrated into the generated application, so developers work at the algorithm level while the toolbox handles deployment to the accelerators. In the processing chain presented in this article, the Radar SDK supplies optimized implementations for: Range FFT — SPT accelerator ( rangeFFT ) Doppler FFT — SPT accelerator ( dopplerFFT ) Non-Coherent Combining — SPT accelerator ( NonCohComb ) CFAR — BBE32 DSP accelerator This lets developers prototype and validate the full chain in MATLAB while leveraging the S32R45 SPT, BBE32 DSP, and LAX hardware accelerators in the final deployed application, and it supports both standalone and Processor-in-the-Loop (PIL) execution. 14 Tools and Ecosystem This processing chain brings together products from both MathWorks and NXP. MathWorks MATLAB® Radar Toolbox™ MATLAB Coder™ Embedded Coder® NXP S32R45 radar processor (Cortex-A53 + SPT + BBE32 DSP + LAX) NXP S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 NXP Model-Based Design Toolbox for SPT 1.9.0 S32 Design Studio 3.6.1 S32R45 – High-Performance Processor for Imaging Radar 15 Conclusion The FMCW radar processing chain transforms the raw radar cube into a compact set of target descriptors through a sequence of well-defined stages. Starting from time-domain samples, range and velocity are extracted with FFT operations, detections are found through adaptive thresholding and grouped into targets, and angle estimation leverages antenna diversity to determine direction. Each final target is characterized by the tuple (range, velocity, angle). By mapping these stages onto the S32R45 Cortex-A53, SPT, BBE32 DSP, and LAX resources through the NXP Radar SDK and the NXP Model-Based Design Toolbox for RADAR, the entire chain can be prototyped in MATLAB and deployed to dedicated radar hardware within a single Model-Based Design workflow.
View full article
Zone Node Software & Hardware Environment 1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion 2 Introduction This article is part of the Zone Node series and describes the software and hardware environment used throughout the project. The purpose of this article is to describe the software and hardware setup required to follow the series and reproduce the results. Before examining communication routing, control logic, or integration challenges, it is important to understand the tools and platforms that support the development and execution of the zonal node application. This article introduces the software components used to develop, configure, and deploy the application, as well as the hardware platforms used to demonstrate the zonal controller functionality. This information provides the foundation required for the remaining articles in the series. Overview of the development flow The zonal node application presented in this series is developed using a combination of Model-Based Design tools, NXP software components, and automotive-grade hardware platforms. At a high level: Application modeling starts in MATLAB® and Simulink®, where communication routing and control logic are implemented graphically. Code generation converts the model into production-ready embedded software using the code-generation tools provided by MathWorks and NXP. Deployment compiles the generated software and loads it onto the target hardware, where it is used to demonstrate communication between multiple vehicle networks. This environment was selected to support rapid development, easier validation, and improved traceability between model design and generated software. By using a Model-Based Design approach, algorithm development, communication integration, and application verification can be performed within a common framework. The software and hardware presented here are used consistently throughout the series and will be referenced when discussing communication routing, system behavior, and integration scenarios. Figure 1. Development flow diagram The workflow begins with application development in Simulink. Communication routing logic, control functions, and software configuration are implemented within the model. The NXP Model-Based Design Toolbox (MBDT) provides hardware-specific blocks that enable integration with S32K3 peripherals and communication interfaces. Following code generation, the application is compiled and deployed to the target hardware, where communication routing functionality can be validated. This article is intended for: Engineers interested in reproducing the zonal node demonstration Simulink users developing automotive communication applications Developers evaluating Model-Based Design workflows Engineers working with NXP automotive microcontrollers and evaluation boards By understanding the software and hardware environment early in the series, readers will be better prepared to follow the implementation details presented in subsequent articles. 3 Required Software The following software components are used throughout the project: MATLAB® and Simulink® – model development and simulation Embedded Coder® (required MATLAB toolbox) – automatic code generation from the model Simulink models – the zonal node routing application model referenced throughout the series NXP Model-Based Design Toolbox (MBDT) – S32K3 support and peripheral configuration NXP additional tools – FreeMASTER and S32 Design Studio for build, deployment, and debugging CAN analysis software – monitoring and validating CAN communication LIN analysis software – monitoring and validating LIN communication 3.1 MATLAB® and Simulink® MATLAB® and Simulink® form the foundation of the development environment. They are used to create the zonal node application, implement communication routing logic, configure software behavior, and perform model-based verification activities. The application described throughout this series is developed as a Simulink model and later translated into embedded software using automatic code-generation tools (Embedded Coder®). 3.2 NXP Model-Based Design Toolbox (MBDT) The NXP Model-Based Design Toolbox (MBDT) extends Simulink with hardware-specific support for NXP automotive microcontrollers. For this project, MBDT for S32K3 version 1.8.0 is used. The toolbox provides blocks and configuration interfaces for communication peripherals, timers, digital I/O resources, and other hardware modules available on the target device. It also integrates with the code-generation workflow, allowing Simulink models to be converted into software that can run directly on the S32K3 microcontroller. Note: Installation and configuration instructions are provided in the dedicated article series (How to install .MLTBX). Readers who have not yet installed the toolbox should complete that step before continuing with this series. 3.3 CAN Analysis Software CAN analysis tools are used during development and validation to observe CAN and CAN FD traffic exchanged between the zonal node and other network participants. Typical use cases include: Monitoring transmitted and received CAN frames Verifying CAN-to-CAN routing behavior Measuring message timing and bus utilization Troubleshooting communication issues Examples of commonly used software include PCAN-View, CANalyzer, and CANoe. 3.4 LIN Analysis Software LIN analysis tools are used to monitor communication between the zonal node and LIN-connected edge devices. Typical use cases include: Verifying LIN schedule execution Monitoring frame transmission and reception Validating signal timing and integrity Testing LIN-to-CAN routing scenarios Examples of commonly used software include PLIN-View and LINalyzer. 4 Required Hardware The following hardware components are used throughout the project: S32K344 automotive microcontroller – used to execute the zonal node application S32K344-WB Evaluation Board – used as the development and validation platform CAN analysis hardware – used to monitor and verify CAN/CAN FD communication LIN analysis hardware – used to monitor and verify LIN communication 4.1 S32K3 Microcontroller The S32K3 family provides: Arm® Cortex®-M7 processing cores CAN FD communication interfaces LIN communication support Safety-oriented automotive features Low-power operating modes Rich peripheral connectivity These capabilities make the device suitable for implementing communication aggregation and routing functions within the scope of this project. 4.2 Evaluation Hardware The zonal node application runs on the S32K344-WB Evaluation Board, a development platform based on the NXP S32K344 microcontroller. The board provides access to the communication interfaces and processing capabilities of the target device while offering an integrated platform for software development, debugging, and validation activities. Within the scope of this project, the board is used to execute the routing application and exchange messages with nodes connected through CAN and LIN networks. Its communication interfaces, debugging connectivity, and expansion capabilities make it suitable for evaluating zonal communication architectures and routing scenarios. Figure 2. S32K344-WB evaluation board 4.3 Communication Networks The examples presented throughout this series use CAN and LIN networks to demonstrate message forwarding, routing, and protocol translation scenarios. These networks provide the communication backbone between the zonal node, central controller, and edge nodes, and are referenced throughout the upcoming routing and integration articles. 4.4 Network Analysis Hardware Additional hardware tools are used during development and validation to observe network traffic and verify communication behavior. CAN analysis interfaces can be connected to the network to monitor transmitted and received CAN/CAN FD frames, validate routing functionality, and troubleshoot communication issues. LIN analysis interfaces can be used to monitor LIN schedules, frame exchanges, and LIN-to-CAN routing scenarios. These tools provide visibility into network activity and support verification of the communication flows presented in later articles of this series. 5 References Model-Based Design Toolbox (MBDT) Embedded Coder® Documentation MATLAB® and Simulink® Documentation S32K3 Microcontrollers S32K344-WB Evaluation Board 6 Conclusion This article introduced the software and hardware environment used throughout the zonal node project. It presented the development tools, code-generation workflow, and target hardware that support the implementation of the communication routing application. The next article will build on this foundation by examining the internal logic control mechanisms used within the zonal node and how they contribute to communication handling across multiple networks.
View full article
Processor-in-the-Loop (PIL) 1 Table of Contents •Introduction •Overview •Context •Component Overview •Design and Implementation •Results •Common Pitfalls & Troubleshooting •Summary & Next Steps •References 2 Introduction A virtual vehicle can reproduce vehicle dynamics, driver inputs, road scenarios, sensor stimuli, and network communication long before the complete physical vehicle is available. However, a successful desktop simulation answers only one part of the engineering question: does the algorithm behave correctly as a model? Processor-in-the-Loop (PIL) adds the target processor to the validation loop. The plant, scenario, and test harness remain in MATLAB ® and Simulink ® , while selected generated algorithm code is cross-compiled, downloaded, and executed on the NXP processor. Inputs are sent from the host to the target, and the computed outputs are returned to the simulation for comparison and analysis. This makes PIL the bridge between a virtual vehicle that behaves correctly on the development computer and embedded software that must produce equivalent results on its intended processor. It also provides target-based execution-time measurements, helping engineers assess whether an algorithm is not only functionally correct, but also suitable for its timing budget. 3 Overview This article presents how Processor-in-the-Loop fits into a Model-Based Design workflow for virtual vehicle development. The goal is to show where PIL adds value between desktop simulation and deeper hardware integration, and how the same virtual vehicle and scenario can be reused to validate generated code on the target processor. In this workflow, the model remains the starting point. The virtual vehicle provides the plant behavior, the simulated environment provides repeatable driving conditions, and the selected algorithm is generated and executed on target hardware. PIL therefore supports a controlled transition from model behavior to target implementation behavior. Figure 1. PIL connects virtual vehicle simulation with generated algorithm execution on target hardware. 4 Context The practical context for this article is the Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. project. In that setup, driver inputs come from a physical steering wheel and pedals, the vehicle is driven through a RoadRunner simulated environment, and an S32N processor communicates with the host simulation while making vehicle-level decisions. The virtual vehicle is created with MathWorks tools and reused as the common integration point for driver inputs, vehicle behavior, RoadRunner scene interaction, Unreal Engine visualization, CAN communication, and closed-loop feedback from the physical setup. From that perspective, PIL is not used to move the entire virtual world to the processor. Instead, the virtual vehicle and simulated scenario remain on the host while selected generated algorithms are executed on the target. This keeps the environment flexible and repeatable while bringing processor behavior into the validation loop. 5 Component Overview A PIL-enabled virtual vehicle workflow combines the following elements: Virtual vehicle - represents vehicle dynamics, driver interaction, powertrain, steering, braking, CAN communication, and feedback paths. Virtual scene and scenario - provides roads, lanes, signs, intersections, actors, traffic movement, and repeatable test conditions using RoadRunner and Unreal Engine. PIL component - contains the selected generated algorithm code that is cross-compiled and executed on the target processor. S32N main node - acts as an aggregator and decision-maker, receiving information from sensing nodes and sending high-level commands to actuator nodes. S32N positioning: S32N is a suitable solution for running complex central-compute algorithms in PIL because it is positioned at the point where vehicle-level decisions, aggregated data, CAN communication, and actuator commands come together. 6 Design and Implementation A practical PIL workflow starts by selecting a bounded algorithm and keeping the plant, scene, and test harness on the host. This makes the test setup easier to control and keeps the comparison focused on the generated target implementation. 6.1 Select the algorithm boundary Relevant candidates include data aggregation, vehicle-level decision logic, Automated Emergency Braking logic, actuator command generation, CAN signal processing, and telemetry preparation. 6.2 Create repeatable virtual tests Use the simulated environment to define controlled driving conditions such as road geometry, actors, traffic movement, obstacle placement, and driver commands. The same scenario can be replayed for model and PIL execution. 6.3 Establish the model baseline Run the selected scenario with the original Simulink implementation and log the component inputs, outputs, and vehicle-level signals required for comparison. 6.4 Run the generated implementation in PIL Generate and build the selected component for the supported S32N5 target configuration. During the PIL run, Simulink sends test vectors to the target and receives the target results while the rest of the virtual vehicle continues to execute on the host. 6.5 Compare and profile Compare model and PIL outputs using the acceptance criteria defined for the algorithm. Where supported, collect target-side execution-time data to evaluate whether the generated component fits its timing budget. (function() { var wrapper = document.getElementById('lia-vid-6401636318112w386h386r961'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) PIL Setup on S32N5. 7 Results The result of this workflow is a direct comparison between model behavior and generated code running on the target. A useful result set shows whether target outputs remain equivalent to model outputs, whether decision thresholds and state transitions occur under the same scenario conditions, and whether the target-side execution time fits the assigned budget. Because the virtual scenes are controlled and repeatable, failing cases can be preserved as regression scenarios and rerun after model, configuration, or implementation changes. (function() { var wrapper = document.getElementById('lia-vid-6401636809112w960h540r168'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) 8 Common Pitfalls & Troubleshooting The PIL boundary is too large - keep the virtual world, visualization, and detailed plant on the host. Simulation time is confused with target execution time - use target-side profiling for algorithm timing conclusions. Model and target interfaces differ - keep signal definitions, data types, scaling, units, and sample times consistent. CAN definitions are inconsistent - reuse the same DBC definitions across the simulation and physical network. PIL is treated as complete system validation - PIL validates selected generated code on the processor; full distributed-system behavior still requires later integration stages. 9 Summary & Next Steps PIL connects the virtual vehicle, simulated scenarios, and S32N5 target execution into one validation flow. The host continues to simulate the driver, vehicle, road, actors, and environment, while selected generated main-node algorithms execute on the S32N5. A practical next step is to select one bounded S32N5 function, define its acceptance criteria, and replay a representative RoadRunner scenario first with the model and then in PIL. Suitable starting points include data aggregation, AEB decision logic, high-level actuator command generation, or CAN signal processing. 10 References Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. Creating virtual vehicle with MathWorks - Overview Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine) MathWorks: Processor-in-the-Loop Simulation
View full article