Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
RT600 4 I2S input to 1 TDM output solution 1. Abstract This article aims to implement the simultaneous input of 4 groups of 48Khz 32bit 2ch audio data on the RT685 platform, and then assemble the received data into a 48Khz 32bit 8ch audio and output it through I2S. This solution is also done at the request of customers, because there are always harmonic problems when customers make it. After analyzing the customer's situation, it is found that the customer has two main problems: (1) Harmonic problem: After receiving 4 channels of 8 bytes, it is directly copied to the sending buffer. This will cause timing problems. It does not take into account the problem of buffering data in the audio data storage pool. The time required to receive enough audio data is at least greater than the time required for copying and sending. Therefore, the problem is reflected in the problem that the customer found harmonic problems when testing the output audio waveform. (2) Audio synchronization problem: After the customer received 4 channels of audio data, he tested the receiving buffer and found that the 4 channels of data were out of sync. Therefore, in order to help customers, I helped customers make this application demo directly, and made a matching test audio source to send a set of 48Khz sampling rate 32bit dual-channel, fixed increment audio data in a loop, such as 0X00-0XFF in a loop. The following is the block diagram of this application platform:   1.jpg Figure 1 System Block Diagram In the above figure, a MIMXRT685-EVK implements the function of outputting 48Khz, 32bit*2ch, and sends data in a loop: 0X00, 0X01….0XFF. Another MIMXRT685-EVK is the focus of this article, which implements 4 groups of I2S to receive data at a sampling rate of 48khz and 32bit*2ch, and then assembles the received data into audio data with a sampling rate of 48Khz and 32bit*8ch and sends it out. In the above figure, in order to reduce the connection of external lines, for BCLK and WS signals, only one group is directly connected to I2S3, and the other I2S2, I2S4, and I2S5 share the I2S3 signal internally. Then, for DATA data, a line is made externally with 4 heads, and connected to the data pins of each group of audio interfaces respectively. The following is a detailed description of this solution. 2. Hardware platform establish The pinouts of the two boards are given below. Because the platform uses many pins, specific allocation is required. 2.1 Audio source board A MIMXRT685-EVK is used as an audio source, and the pinouts for sending 48Khz 32bit*2ch are as follows:   2.jpg Figure 2 Pinout of audio source board 2.2 Audio transceiver board Another MIMXRT685-EVK is used as an audio transceiver board to receive 4-channel audio synchronization data sent by the audio source and assemble it into a 48Khz 32bit*8ch waveform for transmission.   3.jpg Figure 3 Pin assignment of audio transceiver board 2.3 Dual-board hardware connection The source and target connections of the two boards are as follows:   4.jpg Figure 4 Two board pin connection   5.jpg Figure 5 two board connection After the hardware is ready, the software solution and code are provided. 3. Software solution and software implementation In the process of writing the code, we tried many solutions, such as: (1) When receiving, directly assemble it into the TDM format buffer to be sent, and then send it. However, since it is assembled into TDM, one I2S needs to receive 8 byte per frame, and then do the offset to receive the next one. If the reception is carried out according to the 8-byte DMA, the callback of the 4 groups of I2S will enter frequently, resulting in a large CPU load, so this solution is abandoned. (2) The 4 groups of I2S are connected to each other, and the 10ms buffer is connected, and then the DMA method is used to copy from memory to memory. However, since the DMA of RT685 is relatively weak, it can only achieve a maximum offset of 32bit 4word=16byte, that is, a 16-byte offset. However, in fact, a group of audio data is 32bit*2, and 4 groups are 32bit*8=32byte offset, so DMA cannot meet the requirements. Therefore, the DMA memory-to-memory copy solution is abandoned and memcpy is used instead. (3) Use the I2S_RxTransferReceiveDMA function to perform DMA reception. However, in fact, when one group is called, it starts receiving directly, and waits until the next group of I2S interfaces calls I2S_RxTransferReceiveDMA. This has caused an asynchronous situation. Even if the I2S enable is turned off in I2S_RxTransferReceiveDMA, the 4th group of I2S is enabled after the several groups of I2S of I2S_RxTransferReceiveDMA are called. This method can only achieve the synchronization of the reception of the first group of data, because later, it is necessary to go to the callback to re-trigger the reception of the second frame of data. Therefore, the callback of the 4 groups of I2S calls I2S_RxTransferReceiveDMA, which will inevitably cause new synchronization problems. Therefore, this method is abandoned and it is considered to use two groups of DMA descriptors to do ping-pong. In this way, the reception will continue in a loop without the intervention of CPU code. 3.1 Solution Implementation Several solutions have been described above. Finally, we choose to use 4 audio channels to receive audio data and cache 10ms audio data buffer. The conversion from receiving buffer to sending buffer adopts memcpy method, and test whether this copy time can meet the actual needs, to ensure that the buffer pool of receiving buffer is greater than this copy time, which is enough to prepare the sending buffer. The solution for receiving data transfer is as follows:   6.jpg Figure 6 Data buffer transfer The above is 4 groups of I2S receiving their own 10ms data respectively. The buffer is actually prepared for 20ms. A single DMA receives a frame for 10ms, and the other 10ms is used for pingpong buffer. The sending buffer is used to copy the received 4 groups of I2S buffers into a 32bit*8ch array in TDM format, and then two groups of ping-pong buffers are also made. In fact, it is to cache 10ms data. The buffer prepares two groups of 10ms. When the first 10ms frame is received, the second buffer is used to receive it. At the same time, the data of the first buffer is copied to the first buffer of the sending buffer, and the first buffer is used for sending. After the sending is completed, it is transferred to the second buffer to receive and send. In this way, as long as the time is controlled well, there will be no data error problem. The data volume of 10ms is 3840Byte, because the receiving frequency is 48Khz, that is, there are 48000 frames in 1s, and each frame is 32bit*2=8Byte, then 10ms=>4800*8Byte=38400Byte. 3.2 Software code implementation The software code implementation part is mainly divided into 4 I2S receiving signal sharing, I2S DMA pingpong configuration, data transfer, sending I2S and other parts. The details are given below 3.2.1 4-way I2S receiving From the above, we can know that the 4 I2S receiving signal is not completely connected with wires, but adopts the method of sharing BCLK and WS signals and receiving DATA separately. I2S2, I2S4, I2S5 share the BCLK of I2S3, and the WS code is as follows: /* Set shared signal set 0: SCK, WS from Flexcomm1 */ I2S_BRIDGE_SetShareSignalSrc(kI2S_BRIDGE_ShareSet0, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_Flexcomm3); I2S_BRIDGE_SetShareSignalSrc(kI2S_BRIDGE_ShareSet0, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_Flexcomm3); /* Set flexcomm3 SCK, WS from shared signal set 0 */ I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm2, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm2, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm4, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm4, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm5, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm5, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_ShareSet0); 3.2.2 I2S DMA pingpong configuration In order to achieve 4-channel audio synchronization and receive 10ms audio buffer, two I2S DMA descriptors are used to implement the ping-pong function to collect data to two ping-pong buffers in turn. The code is as follows: #define I2S_BUFFER_SIZE 3840 //10ms SDK_ALIGN(static dma_descriptor_t I2S2_s_rxDmaDescriptors[2U], FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE); SDK_ALIGN(static dma_descriptor_t I2S3_s_rxDmaDescriptors[2U], FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE); SDK_ALIGN(static dma_descriptor_t I2S4_s_rxDmaDescriptors[2U], FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE); SDK_ALIGN(static dma_descriptor_t I2S5_s_rxDmaDescriptors[2U], FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE); SDK_ALIGN(static uint8_t I2S2_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S3_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S4_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S5_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); static i2s_transfer_t I2S2_s_RxTransfer[2] = {{ .data = I2S2_s_Buffer[0], .dataSize = I2S_BUFFER_SIZE, }, { .data = I2S2_s_Buffer[1], .dataSize = I2S_BUFFER_SIZE, }}; static i2s_transfer_t I2S3_s_RxTransfer[2] = {{ .data = I2S3_s_Buffer[0], .dataSize = I2S_BUFFER_SIZE, }, { .data = I2S3_s_Buffer[1], .dataSize = I2S_BUFFER_SIZE, }}; static i2s_transfer_t I2S4_s_RxTransfer[2] = {{ .data = I2S4_s_Buffer[0], .dataSize = I2S_BUFFER_SIZE, }, { .data = I2S4_s_Buffer[1], .dataSize = I2S_BUFFER_SIZE, }}; static i2s_transfer_t I2S5_s_RxTransfer[2] = {{ .data = I2S5_s_Buffer[0], .dataSize = I2S_BUFFER_SIZE, }, { .data = I2S5_s_Buffer[1], .dataSize = I2S_BUFFER_SIZE, }}; I2S_RxGetDefaultConfig(&I2S2_s_RxConfig); I2S2_s_RxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; I2S2_s_RxConfig.masterSlave = DEMO_I2S_TX_MODE;//DEMO_I2S_RX_MODE I2S_RxInit(DEMO_I2S2_RX, &I2S2_s_RxConfig); I2S_RxGetDefaultConfig(&I2S3_s_RxConfig); I2S3_s_RxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; I2S3_s_RxConfig.masterSlave = DEMO_I2S_TX_MODE;//DEMO_I2S_RX_MODE I2S_RxInit(DEMO_I2S3_RX, &I2S3_s_RxConfig); I2S_RxGetDefaultConfig(&I2S4_s_RxConfig); I2S4_s_RxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; I2S4_s_RxConfig.masterSlave = DEMO_I2S_TX_MODE;//DEMO_I2S_RX_MODE I2S_RxInit(DEMO_I2S4_RX, &I2S4_s_RxConfig); I2S_RxGetDefaultConfig(&I2S5_s_RxConfig); I2S5_s_RxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; I2S5_s_RxConfig.masterSlave = DEMO_I2S_TX_MODE;//DEMO_I2S_RX_MODE I2S_RxInit(DEMO_I2S5_RX, &I2S5_s_RxConfig); DMA_Init(DEMO_DMA); DMA_EnableChannel(DEMO_DMA, DEMO_I2S2_RX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S2_RX_CHANNEL, kDMA_ChannelPriority1); DMA_CreateHandle(&I2S2_s_DmaRxHandle, DEMO_DMA, DEMO_I2S2_RX_CHANNEL); I2S_RxTransferCreateHandleDMA(DEMO_I2S2_RX, &I2S2_s_RxHandle, &I2S2_s_DmaRxHandle, I2S2_RxCallback, (void *)&I2S2_s_RxTransfer); DMA_EnableChannel(DEMO_DMA, DEMO_I2S3_RX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S3_RX_CHANNEL, kDMA_ChannelPriority1); DMA_CreateHandle(&I2S3_s_DmaRxHandle, DEMO_DMA, DEMO_I2S3_RX_CHANNEL); I2S_RxTransferCreateHandleDMA(DEMO_I2S3_RX, &I2S3_s_RxHandle, &I2S3_s_DmaRxHandle, I2S3_RxCallback, (void *)&I2S3_s_RxTransfer); DMA_EnableChannel(DEMO_DMA, DEMO_I2S4_RX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S4_RX_CHANNEL, kDMA_ChannelPriority1); DMA_CreateHandle(&I2S4_s_DmaRxHandle, DEMO_DMA, DEMO_I2S4_RX_CHANNEL); I2S_RxTransferCreateHandleDMA(DEMO_I2S4_RX, &I2S4_s_RxHandle, &I2S4_s_DmaRxHandle, I2S4_RxCallback, (void *)&I2S4_s_RxTransfer); DMA_EnableChannel(DEMO_DMA, DEMO_I2S5_RX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S5_RX_CHANNEL, kDMA_ChannelPriority2); DMA_CreateHandle(&I2S5_s_DmaRxHandle, DEMO_DMA, DEMO_I2S5_RX_CHANNEL); I2S_RxTransferCreateHandleDMA(DEMO_I2S5_RX, &I2S5_s_RxHandle, &I2S5_s_DmaRxHandle, I2S5_RxCallback, (void *)&I2S5_s_RxTransfer); I2S_TransferInstallLoopDMADescriptorMemory(&I2S2_s_RxHandle, I2S2_s_rxDmaDescriptors, 2U); I2S_TransferInstallLoopDMADescriptorMemory(&I2S3_s_RxHandle, I2S3_s_rxDmaDescriptors, 2U); I2S_TransferInstallLoopDMADescriptorMemory(&I2S4_s_RxHandle, I2S4_s_rxDmaDescriptors, 2U); I2S_TransferInstallLoopDMADescriptorMemory(&I2S5_s_RxHandle, I2S5_s_rxDmaDescriptors, 2U); if (I2S_TransferReceiveLoopDMA(DEMO_I2S2_RX, &I2S2_s_RxHandle, &I2S2_s_RxTransfer[0], 2U) != kStatus_Success) { assert(false); } if (I2S_TransferReceiveLoopDMA(DEMO_I2S3_RX, &I2S3_s_RxHandle, &I2S3_s_RxTransfer[0], 2U) != kStatus_Success) { assert(false); } if (I2S_TransferReceiveLoopDMA(DEMO_I2S4_RX, &I2S4_s_RxHandle, &I2S4_s_RxTransfer[0], 2U) != kStatus_Success) { assert(false); } if (I2S_TransferReceiveLoopDMA(DEMO_I2S5_RX, &I2S5_s_RxHandle, &I2S5_s_RxTransfer[0], 2U) != kStatus_Success) { assert(false); } I2S_Enable(DEMO_I2S2_RX); I2S_Enable(DEMO_I2S3_RX); I2S_Enable(DEMO_I2S4_RX); I2S_Enable(DEMO_I2S5_RX); Here, the code has been modified, mainly the I2S_TransferLoopDMA function in fsl_i2s_dma.c, which is blocked: I2S_Enable(base); In order to realize the function of 4-channel synchronous reception. 3.2.3 Audio data received and transferred Because when receiving, each audio interface takes turns to receive its own 2ch data, but when sending, it is necessary to send 4-channel received audio dual-channel data, that is, 32bit*8ch data, so after receiving ping, the ping data needs to be transferred to the sending ping buffer. The code for transfer is as follows: #define I2S_BUFFER_SIZE 3840 //10ms SDK_ALIGN(static uint8_t I2S2_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S3_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S4_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S5_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S1_s_Buffer[2][I2S_BUFFER_SIZE*4], sizeof(uint32_t)); if( s_pingpong == 1) { for(ch = 0;ch < 480; ch++) //480=I2S_BUFFER_SIZE(3840)/8 { memcpy(&I2S1_s_Buffer[0][0 + (32*ch)], &I2S2_s_Buffer[0][8*ch], 8); memcpy(&I2S1_s_Buffer[0][8 + (32*ch)], &I2S3_s_Buffer[0][8*ch], 8); memcpy(&I2S1_s_Buffer[0][16 + (32*ch)], &I2S4_s_Buffer[0][8*ch], 8); memcpy(&I2S1_s_Buffer[0][24 + (32*ch)], &I2S5_s_Buffer[0][8*ch], 8); } } else { for(ch = 0;ch < 480; ch++) { memcpy(&I2S1_s_Buffer[1][0 + (32*ch)], &I2S2_s_Buffer[1][8*ch], 8); memcpy(&I2S1_s_Buffer[1][8 + (32*ch)], &I2S3_s_Buffer[1][8*ch], 8); memcpy(&I2S1_s_Buffer[1][16 + (32*ch)], &I2S4_s_Buffer[1][8*ch], 8); memcpy(&I2S1_s_Buffer[1][24 + (32*ch)], &I2S5_s_Buffer[1][8*ch], 8); } } 3.2.4 Send TDM audio code The sending code also uses the I2S DMA method, but because there is no need to send multiple channels at the same time, only a single channel, there is no need to consider the synchronization problem, and no DMA descriptor is used. After the sending buffer is ready, the I2S_TxTransferSendDMA method is used. The code is as follows: I2S_TxGetDefaultConfig(&I2S1_s_TxConfig); I2S1_s_TxConfig.divider = DEMO_I2S1_CLOCK_DIVIDER; I2S1_s_TxConfig.masterSlave = kI2S_MasterSlaveNormalMaster; I2S1_s_TxConfig.wsPol = true; I2S1_s_TxConfig.mode = kI2S_ModeDspWsLong;//kI2S_ModeDspWsShort; I2S1_s_TxConfig.dataLength = 32U; I2S1_s_TxConfig.frameLength = 32 * 8U; I2S1_s_TxConfig.position = DEMO_TDM_DATA_START_POSITION; I2S1_s_TxConfig.pack48 = true; I2S_TxInit(DEMO_I2S1_TX, &I2S1_s_TxConfig); I2S_EnableSecondaryChannel(DEMO_I2S1_TX, kI2S_SecondaryChannel1, false, 64 + DEMO_TDM_DATA_START_POSITION); I2S_EnableSecondaryChannel(DEMO_I2S1_TX, kI2S_SecondaryChannel2, false, 128 + DEMO_TDM_DATA_START_POSITION); I2S_EnableSecondaryChannel(DEMO_I2S1_TX, kI2S_SecondaryChannel3, false, 192 + DEMO_TDM_DATA_START_POSITION); DMA_EnableChannel(DEMO_DMA, DEMO_I2S1_TX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S1_TX_CHANNEL, kDMA_ChannelPriority3); DMA_CreateHandle(&I2S1_s_DmaTxHandle, DEMO_DMA, DEMO_I2S1_TX_CHANNEL); I2S_TxTransferCreateHandleDMA(DEMO_I2S1_TX, &I2S1_s_TxHandle, &I2S1_s_DmaTxHandle, I2S1_TxCallback, (void *)&I2S1_s_TxTransfer); if( s_pingpong == 1) { I2S1_s_TxTransfer.data = I2S1_s_Buffer[0]; I2S1_s_TxTransfer.dataSize = I2S_BUFFER_SIZE*4; I2S_TxTransferSendDMA(DEMO_I2S1_TX, &I2S1_s_TxHandle, I2S1_s_TxTransfer); } else { I2S1_s_TxTransfer.data = I2S1_s_Buffer[1]; I2S1_s_TxTransfer.dataSize = I2S_BUFFER_SIZE*4; I2S_TxTransferSendDMA(DEMO_I2S1_TX, &I2S1_s_TxHandle, I2S1_s_TxTransfer); } 3.2.5 Send and receive I2S callback processing For the receiving I2S2, 3, 4, 5, there are 4 channels in total. Each time 10ms of data is received, a callback will be entered. In the callback, you only need to record the flag. When all 4 flags are recorded, it means that the 4 channels of the same 10ms data have been received, and the data can be copied to the sending buffer. Of course, in order to test whether the callback entry frequency is once every 10ms, this article makes a GPIO callback for testing. The following is the code for recording I2S callback static void I2S2_RxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { s_allRXTriggerred |= 0x01; } static void I2S3_RxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { s_allRXTriggerred |= 0x02; } static void I2S4_RxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { s_allRXTriggerred |= 0x04; } static void I2S5_RxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { /* Enqueue the same original buffer all over again */ s_allRXTriggerred |= 0x08; GPIO_PortToggle(GPIO, 1, 1<<0); if( s_pingpong == 0) { s_pingpong = 1; } else { s_pingpong = 0; } } static void I2S1_TxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { GPIO_PortToggle(GPIO, 1, 1<<8); //__NOP(); } So far, all functions of a MIMXRT685-EVK for 4 I2S reception and 1 I2S TDM transmission have been completed. 3.2.6 Audio source code The audio source is made on another MIMXRT685-EVK to send 48Khz, 32bit*2ch audio data, and the data is sent in a loop from 0X00 to 0XFF. The code is as follows: int main(void) { BOARD_InitBootPins(); BOARD_InitBootClocks(); BOARD_InitDebugConsole(); BOARD_I3C_ReleaseBus(); BOARD_InitI3CPins(); CLOCK_EnableClock(kCLOCK_InputMux); /* attach main clock to I3C (500MHz / 20 = 25MHz). */ CLOCK_AttachClk(kMAIN_CLK_to_I3C_CLK); CLOCK_SetClkDiv(kCLOCK_DivI3cClk, 20); /* attach AUDIO PLL clock to FLEXCOMM1 (I2S1) */ CLOCK_AttachClk(kAUDIO_PLL_to_FLEXCOMM1); /* attach AUDIO PLL clock to FLEXCOMM3 (I2S3) */ CLOCK_AttachClk(kAUDIO_PLL_to_FLEXCOMM3); /* attach AUDIO PLL clock to MCLK */ CLOCK_AttachClk(kAUDIO_PLL_to_MCLK_CLK); CLOCK_SetClkDiv(kCLOCK_DivMclkClk, 1); SYSCTL1->MCLKPINDIR = SYSCTL1_MCLKPINDIR_MCLKPINDIR_MASK; wm8904Config.i2cConfig.codecI2CSourceClock = CLOCK_GetI3cClkFreq(); wm8904Config.mclk_HZ = CLOCK_GetMclkClkFreq(); /* Set shared signal set 0: SCK, WS from Flexcomm1 */ I2S_BRIDGE_SetShareSignalSrc(kI2S_BRIDGE_ShareSet0, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_Flexcomm1); I2S_BRIDGE_SetShareSignalSrc(kI2S_BRIDGE_ShareSet0, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_Flexcomm1); /* Set flexcomm3 SCK, WS from shared signal set 0 */ I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm3, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm3, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_ShareSet0); #if 1 PRINTF("Configure codec\r\n"); /* protocol: i2s * sampleRate: 48K * bitwidth:16 */ if (CODEC_Init(&codecHandle, &boardCodecConfig) != kStatus_Success) { PRINTF("codec_Init failed!\r\n"); assert(false); } /* Initial volume kept low for hearing safety. * Adjust it to your needs, 0-100, 0 for mute, 100 for maximum volume. */ if (CODEC_SetVolume(&codecHandle, kCODEC_PlayChannelHeadphoneLeft | kCODEC_PlayChannelHeadphoneRight, DEMO_CODEC_VOLUME) != kStatus_Success) { assert(false); } PRINTF("Configure I2S\r\n"); #endif /* * masterSlave = kI2S_MasterSlaveNormalMaster; * mode = kI2S_ModeI2sClassic; * rightLow = false; * leftJust = false; * pdmData = false; * sckPol = false; * wsPol = false; * divider = 1; * oneChannel = false; * dataLength = 16; * frameLength = 32; * position = 0; * watermark = 4; * txEmptyZero = true; * pack48 = false; */ I2S_TxGetDefaultConfig(&s_TxConfig); s_TxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; s_TxConfig.masterSlave = DEMO_I2S_TX_MODE; I2S_TxInit(DEMO_I2S_TX, &s_TxConfig); DMA_Init(DEMO_DMA); DMA_EnableChannel(DEMO_DMA, DEMO_I2S_TX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S_TX_CHANNEL, kDMA_ChannelPriority3); DMA_CreateHandle(&s_DmaTxHandle, DEMO_DMA, DEMO_I2S_TX_CHANNEL); StartSoundPlayback(); while (1) { } } static void StartSoundPlayback(void) { PRINTF("Setup looping playback of sine wave\r\n"); s_TxTransfer.data = &g_Music[0]; s_TxTransfer.dataSize = sizeof(g_Music); I2S_TxTransferCreateHandleDMA(DEMO_I2S_TX, &s_TxHandle, &s_DmaTxHandle, TxCallback, (void *)&s_TxTransfer); /* need to queue two transmit buffers so when the first one * finishes transfer, the other immediatelly starts */ I2S_TxTransferSendDMA(DEMO_I2S_TX, &s_TxHandle, s_TxTransfer); I2S_TxTransferSendDMA(DEMO_I2S_TX, &s_TxHandle, s_TxTransfer); } static void TxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { /* Enqueue the same original buffer all over again */ i2s_transfer_t *transfer = (i2s_transfer_t *)userData; I2S_TxTransferSendDMA(base, handle, *transfer); } Audio data buffer:   7.jpg Figure 7 Audio source sends buffer The corresponding test results are given:   8.jpg Figure 8 Audio source sending data test It can be seen that the data sent by the audio source is cyclical and can be sent in an increasing loop. 4. Test results There are several points to verify about the test results: (1) 4-channel audio receives pingpong buffer, whether a single buffer is 10ms, that is, a 10ms audio data pool. (2) How long is the data memory copy time, whether it will exceed the length of the receiving audio data pool. (3) Whether the received 4-channel data is synchronized, whether the assembled send buffer data is the 32bit*8ch data assembled from the corresponding 4-channel 2ch data. (4) Whether the sent audio waveform is the correct 32bit*8ch TDM data. The following are the verification test results for these points. 4.1 4 I2S audio 10ms data pool This verification is very simple. Define a pin GPIO, initialize the output to 0, and then reverse it in the received callback interrupt. This article chooses to reverse it in the I2S5 callback. The test results are as follows:   9.jpg Figure 9 ch1 10ms duration Channel 1 is the exact 10ms because of the callback reversal received. Here is a general picture of the test:   10.jpg Figure 10 Time test overview Ch1: I2S5 callback entry frequency Ch2: memory copy time Ch3: Send callback entry frequency It can be seen that the frequency of sending and receiving is 10ms, because the sending frequency is also 48Khz, but because it is 8ch, the data volume is 4 times that of receiving, and all the data of the 4 receiving channels need to be stuffed in. 4.2 Time consumption of receiving and copying to sending buffer For data copying, that is, assembling the data received from 4 I2S channels into 4 buffers into the sending buffer, this time test is on the second channel of the oscilloscope, and the results are as follows:   11.jpg Figure 11 copy data time It can be seen that the copying time is less than 500us, which is much shorter than the 10ms of the audio receiving data pool. Therefore, you can use memcpy casually without worrying about the copying time being too long. This also makes up for the regret that I wanted to use DMA for memory to memory copying before, but it could not be realized due to DMA performance issues. 4.3 Verification of the synchronization of the data received on the 4 I2S In order to verify the synchronization, this article closes the 4 I2S receiving channel after receiving 100times 10ms, and prints out the corresponding 4 I2S audio receiving buffer. The results of the 4 I2S buffer are as follows:   12.jpg Figure12 I2S2 receive buffer   13.jpg Figure 13 I2S3 receive buffer   14.jpg Figure 14 I2S4 receive buffer   15.jpg Figure 15 I2S5 receive buffer It can be seen that the receive buffer data of the 4 I2S are completely synchronized, and all start from 0XB8. 4.4 Send buffer corresponding to 4-channel audio TDM The send buffer is printed after 100 receptions, and then memcpy is performed to the send buffer, and the printout of the send buffer data is as follows:   16.jpg Figure 16 I2S1 transfer buffer It can be seen that the buffer also starts from 0XB8, and the 4 groups of received data are copied to the send buffer and assembled into 32bit*8ch data. It can be seen that the TDM send buffer is also correct. 4.5 Sending 48Khz 32bit 8ch audio data waveform   17.jpg Figure 17 Transmitting and receiving audio waveforms The upper group is the waveform of the audio source, and the lower group is the waveform of TDM transmission. Due to the limitation of the analysis software of the logic analyzer, it can only analyze 2ch 64bit data at most, so only part of the data can be seen here, but from the waveform, it can be seen that the waveform of sending TDM can achieve 32bit*8ch, and every 8byte data in a frame is the same, which also explains the synchronization of 4-channel audio reception. In the above figure, the data of ch2 is actually 00, 01, 02, 03, 04, 05, 06, 07, 4 groups of the same data in one frame, and the waveform can also be seen that there are 4 groups of the same data, and 4 groups of 2ch are enough to form 32bit 8ch TDM. Finally, here is another TDM waveform tested on the oscilloscope:   18.jpg Figure 18 Sending TDM waveform It can be seen that BCLK=12.28Mhz is consistent with the expected 48khz*32bit*8=12.288Mhz. The WS signal is also measured to be 48Khz, which meets the set 48Khz sampling rate. DATA is also transmitting with data changes, and it can be seen that the waveform pattern within a frame is repeated by about 4 groups, which also shows that the 4 groups of received data are synchronized. So far, the function of RT600 4-channel 48KHZ 32bit*2ch input and assembling into 48Khz 32bit*8ch output has been realized! i.MXRT 600 Re: RT600 4 I2S input to 1 TDM output solution Thanks so much for my colleage's help, my best internal Collaborators, my audio mentor!  @james_fan !!!  Also thanks my software colleague Qiangzhang( @Skybegonia  ), he is very familiar with the SDK, he shares the DMA pingpong demo which speed my application code and at last resolve my sync issues.
查看全文
FlexTimer Module (FTM) Usage on S32M24x and S32K14x Series Abstract This document describes how to use the FlexTimer Module on S32M24x and S32K14x series. It introduces several operational modes, including the corresponding implementation to provide reference for different applications. Introduction S32M24x builds on the broad family of S32K14x MCUs, their tools and software by taking select MCUs from that portfolio and co-packaging them with an analog die that supports 12V power management, communications at the physical layer (CAN FD, LIN or CXPI) and the MOSFET gate drivers (6 channels). Based on the above, the FlexTimer Module (FTM) Usage on S32M24x and S32K1xx series can be addressed in same context. Therefore SW and configuration will be quite similar (if not the same) for both devices. However text will be focus on S32M24x implementation. Talking now about the FlexTimer module (FTM), it is built upon a timer with a 16-bit counter. It contains an extended set of features that meet the demands of motor control, including the signed up-counter, dead time insertion hardware, fault control inputs, enhanced triggering functionality, and initialization and polarity control. Software implementation To simplify and accelerate an application development, embedded part of the FTM examples have been created using S32 Design studio, RTD drivers (low level part) and S32K14x/S32M24x is configured using S32 Configuration Tools, see the following figure: Figure 1: S32 Configuration Tools Regarding Peripherals Tool, it allows to configure FTM functionalities though different drivers as follows: Figure 2: FTM Drivers Once you have selected a driver, you could refer for more details to its respective User Manual in the top corner of the FTM Driver Tab: Figure 3: User Manuals for S32K1_S32M24X FTM Drivers Project structure Project structure using S32 Design Studio and RTD for S32K14x and S32M24x version 2.0.0 contains the following components: Figure 4: Project structure Implementation differences between S32M244 and S32K144 devices      Clocking S32M24x and S32K1xx have some spec differences regarding clocking. Additionally, S32M24xEVB-C064 is supplied externally by 16 MHz crystal, meanwhile S32K144EVK is supplied externally by 8 MHz crystal. In Clocks Tool of FTM examples both devices will be configured in Run mode and using PLL as system clock source, the same frequencies will be used for simplicity purposes as follows:      - System and Core clock -> 80MHz      - Bus clock -> 40MHz      - Flash Clock -> 20MHz _Leo__0-1729805873232.png Figure 5: Clocking in S32M24x devices _Leo__1-1729805912193.png Figure 6: Clocking in S32K1xx devices      Pinout S32K144EVK contains a S32K144HFT0VLLT MCU with LQFP 100 package and all its FTM channels are routable to at least to an external pin. Meanwhile S32M24xEVB-C064 contains a S32M244CCABWKHST MCU with LQFP 64 package and not all its FTM channels are routable to an external pin. Such is the case of the following signals: - ftm1_ch1 - ftm1_ch5 Particularly, ftm1_ch1 configuration is required to perform PWM Modulation on FTM0, but even though such channel is not routed to an external pin, such feature on FTM0 can be archived (Please refer to S32M24x/S32K14x-> PWM Modulation Implementation example). FTM examples The FTM examples provided for S32M24x and S32K14x are listed below: • S32M24x/S32K14x -> FTM: Edge-align PWM (EPWM) mode • S32M24x/S32K14x -> FTM: Center-align PWM (CPWM) mode • S32M24x/S32K14x -> FTM: Complementary mode and dead-time insertion • S32M24x/S32K14x -> FTM: Modified Combine PWM Mode for Phase Shift • S32M24x/S32K14x -> FTM: Input capture (In progress) • S32M24x/S32K14x -> FTM: PWM Modulation Implementation • S32M24x/S32K14x -> FTM: Global time base • S32M24x/S32K14x -> FTM: Output compare (In progress) Conclusion This document, together with the linked FTM examples, shows the simplicity and efficiency in using the S32K1xx and S32M24x MCUs for different timing applications. It allows a better understanding of the implementation of FTM functionalities, making it easy, friendly and intuitive for users as well as to properly use this module in their projects. References S32 Design Studio for S32 Platform Real-Time Drivers (RTD) S32M2xx Data Sheet S32M24x Reference Manual S32M24XEVB S32K1xx MCU Family - Data Sheet S32K1xx MCU Family - Reference Manual S32K144EVB AN5303: Features and Operation Modes of FlexTimer Module on S32K
查看全文
为 zeus yocto 层添加 Openjdk 支持 环境:openjdk-8,带有L5.4.24-2.1.0和 GCC-9 1. 使用专用分支名称克隆 meta-java: git clone git://git.yoctoproject.org/meta-java -b zeus 2. 更新 .bbmeta-java 中的编译错误文件: diff --git a/recipes-core/icedtea/icedtea7-native.inc b/recipes-core/icedtea/icedtea7-native.inc index 8d0dc71..153a604 100644 --- a/recipes-core/icedtea/icedtea7-native.inc +++ b/recipes-core/icedtea/icedtea7-native.inc @@ -26,7 +26,7 @@ CXXFLAGS_append = " -fno-tree-dse" CXX_append = " -std=gnu++98" # WORKAROUND: ignore errors from new compilers -CFLAGS_append = " -Wno-error=stringop-overflow -Wno-error=return-type" +CFLAGS_append = " -Wno-error=stringop-overflow -Wno-error=return-type -Wno-error=format-overflow" inherit native java autotools pkgconfig inherit openjdk-build-helper 3. 在 bblayers.conf 中添加 meta-java 层: BBLAYERS += "${BSPDIR}/sources/meta-java" 4.编辑conf/local.conf以添加openjdk变量 # Possible provider: cacao-initial-native and jamvm-initial-native PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native" # Possible provider: cacao-native and jamvm-native PREFERRED_PROVIDER_virtual/java-native = "jamvm-native" # Optional since there is only one provider for now PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native" PREFERRED_PROVIDER_java2-runtime = " openjdk-7-jre" IMAGE_INSTALL_append = " openjdk-7-jdk " diff --git a/recipes-core/openjdk/openjdk-8-common.inc b/recipes-core/openjdk/openjdk-8-common.inc index d8b30b8..ed03d60 100644 --- a/recipes-core/openjdk/openjdk-8-common.inc +++ b/recipes-core/openjdk/openjdk-8-common.inc @@ -181,5 +181,5 @@ FLAGS_GCC9 = "-fno-lifetime-dse -fno-delete-null-pointer-checks" BUILD_CFLAGS_append = " ${@openjdk_build_helper_get_build_cflags(d)}" BUILD_CXXFLAGS_append = " ${@openjdk_build_helper_get_build_cflags(d)}" # flags for -cross -TARGET_CFLAGS_append = " ${@openjdk_build_helper_get_target_cflags(d)}" +TARGET_CFLAGS_append = " ${@openjdk_build_helper_get_target_cflags(d)} -Wno-error=format-overflow" TARGET_CXXFLAGS_append = " ${@openjdk_build_helper_get_target_cflags(d)}" diff --git a/recipes-core/openjdk/openjdk-8-native.inc b/recipes-core/openjdk/openjdk-8-native.inc index 321a43d..97ff03f 100644 5.将主机 GCC 切换为 gcc-8 和 g++-8: sudo apt-get install gcc-8 g++-8 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8 --slave /usr/bin/g++ g++ /usr/bin/g++-8 --slave /usr/bin/gcov gcov /usr/bin/gcov-8 --slave /usr/bin/gcov-tool gcov-tool /usr/bin/gcov-tool-8 --slave /usr/bin/gcc-ar gcc-ar /usr/bin/gcc-ar-8 --slave /usr/bin/gcc-nm gcc-nm /usr/bin/gcc-nm-8 --slave /usr/bin/gcc-ranlib gcc-ranlib /usr/bin/gcc-ranlib-8 sudo update-alternatives --config gcc  6.并将 conf/local.conf 从 openjdk-7 -> openjdk-8 更改: PREFERRED_PROVIDER_java2-runtime = " openjdk-8-jre" IMAGE_INSTALL_append = " openjdk-8 "  i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus
查看全文
i.MX Create NFS Server and Export USB Drive: Yocto Project Distribution Overview i.MX28EVK Setup Build Yocto Project image Create a SDCARD from the Linux Host Boot i.MX28EVK Create file system on USB Create Mount Point and Mount the USB device Create 250 MB File Create Exports File Restart NFS Server Ubuntu Linux Host Setup Create Mount Directory Mount i.MX28EVK Exported Directory Access the NFS mounted directory Overview This document describes the steps for configuring a NFS Server running on an i.MX Application Processor - in this case the evaluation board i.MX28 EVK. Once the NFS server is running, an Ubuntu 12.04 Linux host is then configured to NFS mount the i.MX28EVK exported directory. The Ethernet interface is used for the connection transport. A block diagram of the connection setup is shown below: An Ethernet switch provided the Ethernet connection between the Linux Host and the i.MX28EVK. A thumb drive was connected to the USB port on the i.MX28EVK which was used for the exported directory. i.MX28EVK Setup Build Yocto Project image Use core-image-minimal and add packages to conf/local.conf to support NFS MACHINE=imx28evk source setup-environment mx28-evk echo "CORE_IMAGE_EXTRA_INSTALL += \"bash kernel-modules nfs-utils\" " >> conf/local.conf bitbake core-image-minimal When bitbake finishes the images are found in tmp/deploy/images/imx28evk Create a SDCARD from the Linux Host sudo dd if=/tmp/deploy/images/imx28evk/core-image-minimal-imx28evk.sdcard of=/dev/sdc bs=4M && sync Boot i.MX28EVK Insert the SDCARD into slot 0 on the bottom side of the i.MX28EVK and connect the serial console. Power-on and push the POWER button on the lower conner to turn on. The Login credentials are User Name: root      There is no password configured by default. Create file system on USB The USB drive had one partition which was formatted with vfat file system: mkfs.vfat /dev/sdb1 Create Mount Point and Mount the USB device mkdir /mnt/usb mount /dev/sdb1 /mnt/usb Create 250 MB File dd if=/dev/zero of=/mnt/usb/file1.txt bs=512K count=500 Create Exports File echo "/mnt/usb *(rw,sync,no_root_squash,no_subtree_check)" > /etc/exports Restart NFS Server /etc/init.d/nfsserver stop /etc/init.d/nfsserver start Ubuntu Linux Host Setup Create Mount Directory sudo mkdir /mnt/remote Mount i.MX28EVK Exported Directory sudo mount -t nfs 10.85.1.10:/mnt/usb /mnt/remote Access the NFS mounted directory ls /mnt/remote
查看全文
Example_S32K344_decouple_RTD400_Ip_C40_DS35 ******************************************************************************************************* * Detailed Description: * DCF Record decouples CM7_0 and CM_1 on S32K344 * Find first available location in UTEST. * By default, first available address is 0x1B000768U * * NOTE: There is a bug in the RTD version. * Change FLS_MAX_VIRTUAL_SECTOR to 528 in C40_Ip_Cfg.h * ------------------------------------------------------------------------------ * Test HW: : S32K344EVB-Q257 * MCU: : S32K344 * Project : RTD AUTOSAR 4.7 * Platform : CORTEXM * Peripheral : S32K3XX * Dependencies : none * Autosar Version : 4.7.0 * Autosar Revision : ASR_REL_4_7_REV_0000 * Autosar Conf.Variant : * SW Version : 4.0.0 * Build Version : S32K3_RTD_4_0_0_P20_D2403_ASR_REL_4_7_REV_0000_20240315 ******************************************************************************************************* Re: Example_S32K344_decouple_RTD400_Ip_C40_DS35 Hello @dmitry_buchynski, Thanks for the feedback. It has been fixed. Regards, Daniel Re: Example_S32K344_decouple_RTD400_Ip_C40_DS35_v1 Hello, @danielmartynek  I have a few questions and notes: 1) Is it aplicable for s32k358? 2) In the main.c line 33:      * By default, first available address is 0x1B000780U I suppose it should be 0x1B000768U according to description 3) in the main.c lines 115 and 116:     DCF_record[0] = 0x00000100; /* DCF Control Word */     DCF_record[1] = 0x00100004; /* DCF Data Word, LOCKSTEP = 0 */ I think the comments are incorrect and the first one should be DCF data word and the second DCF control word 4) in the main.c line 116:  DCF_record[1] = 0x00100004; is the parity bit missing here and it actually must be 0x00100006 to match parity with DCF_record[0] = 0x00000100; ? 
查看全文
E9171 AMDPUとT1040 RDBボード 私はE9171 AMDGPUにT1040 NXPボードを搭載していますが、このGPUはamdgpuを使ったパートゥピアデータ転送に対応していますか?このNXPはPCIeスイッチを介してFPGAおよびGPUに接続されています。このGPUはQDMAドライバーを使ってFPGAから直接データを取得できるはずですし、またこのNXPボードはAMDGPUドライバーを使った直接ピアツーピア機能をサポートしていますか? Re: E9171 AMDPU with T1040 RDB Board T1040プラットフォーム上のE9171 + AMDGPUがFPGA→GPU PCIe P2P DMAをサポートしていると考えないでください。現在入手可能なAMDGPUの情報に基づくと、NVIDIA GPUDirect RDMAのように、FPGAとAMDGPU間の直接的なP2P通信は、AMDGPUの標準機能として一般的にはサポートされていません。   AMDGPUはPCIeピアツーピア(P2P)をサポートしていますか? AMDGPUにはLinuxのP2Pインフラストラクチャサポート(PCI_P2PDMA)があり、AMD KFDにはHSA_AMD_P2Pオプションがありますが、このサポートは主に以下の目的で文書化されています: AM GPU ↔ AMD GPU通信 ROCm/HSAコンピューティング環境 GPUが大きなBARを露出し、プラットフォームやチップセットがPCIe P2Pルーティングを可能にするプラットフォーム Linux Kconfigの説明には 、AMDのGPU間のP2P通信が明示的に記載されています。 FPGA→AMD GPUのダイレクトDMAに適用できますか? AMDのエンジニアは次のように公に述べている。 Xilinx FPGAとAMD GPU間のP2Pは現在直接サポートされていません そして、真のデバイス間PCIe DMAの代わりに、ホストメモリ登録の回避策を提案した。 そのため、 パス ステータス AMD GPU ↔ AMD GPU 特定のROCmプラットフォームでサポートされています FPGA ↔ AMD GPUダイレクトPCIe DMA AMDGPUでは一般的にサポートされていません FPGA →ホストDDR → GPU サポートされる FPGA P2Pバッファはホストメモリにマッピングされ、GPUに登録されました   T1040はPCIe P2Pをサポートしていますか? T1040側からは、PCIeハードウェア自体がスイッチを介してメモリ読み書きTLPを転送できる場合、以下の場合に限ります: PCIeスイッチはP2Pルーティングを可能にします。 ACSリダイレクトは無効化されています(スイッチによります)。 住所変換は正しく設定されています。 PCIeというプロトコルは、エンドポイント間のデータ転送を妨げるものではありません。しかし、 T1040/NXPソフトウェアは自動的にAMDGPU-FPGAのP2Pサポートを提供するわけではありません。重要な問題は、次の点である。 AMDGPUはGPUメモリをエクスポートしてサードパーティのDMAアクセス用にします。 FPGA QDMAはGPUのBAR/VRAM物理アドレスを取得することができます。 LinuxのIOMMU/P2PDMAパスはトランザクションを受け入れます。 通常、T1040 PCIeコントローラ自体よりもAMDGPUの制限がブロック要因となっています。 あなたのシステムでうまく機能しそうなものは何ですか? 現在のトポロジー: PCIeスイッチ / \ FPGA(QDMA)E9171 GPU \ / T1040 RC 最も可能性の高いサポートフロー: FPGA →--> DDR(T1040メモリ) | V AMDGPU DMA | VRAM 動作保証はありません: FPGA(QDMA)---> GPU VRAM AMDGPUは一般的に任意のFPGAデバイス向けにGPUDirect-RDMAのようなインターフェースを公開しないからです。
查看全文
SE050E2HQ1/Z01Z3Z所需的热数据 各位同事好, 我正在寻找以下零件编号的热阻数据和工作结温信息: SE050E2HQ1/Z01Z3Z 谢谢,此致敬礼。 残酷的 Smart Card Re: Thermal Data required for SE050E2HQ1/Z01Z3Z 你好@Harsh_Bhavsar , 详情请参阅https://www.nxp.com/docs/en/data-sheet/SE051.pdf 。它们几乎相同。 真挚地, 坎 Re: Thermal Data required for SE050E2HQ1/Z01Z3Z 你好 Kan_Li, 感谢您的回复,数据手册很有帮助。 你能帮我查一下这个器件的最大允许结温吗?或者我可以考虑一下它的工作温度吗? 谢谢,此致敬礼。 残酷的 Re: Thermal Data required for SE050E2HQ1/Z01Z3Z 你好 kan, 这真是非常有用的信息。 谢谢,此致敬礼。 残酷的 Re: Thermal Data required for SE050E2HQ1/Z01Z3Z 你好@Harsh_Bhavsar , 工作时的最大结温仅比工作温度略高,因为内部温度传感器在110°C左右开始触发信号。 祝你有美好的一天, 坎 ------------------------------------------------------------------------------- 笔记: - 如果此回复解答了您的问题,请点击“标记为正确答案”按钮。谢谢你! - 我们会持续关注帖子,从最后一条回复发出后持续7周,之后的回复将被忽略。 如果您之后有相关问题,请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------
查看全文
S32K358 + FS2633:MCUを組み立てた状態でRSTBは低(LOW)のままですが、JTAGがコネクテッド時は高くなります 私はFS2633とS32K358を使用しています。FS2633セクション(MCUを取り外した部分)だけをテストすると、RSTBが解放され(HIGH)、3.3Vレールが存在します。 MCUとすべてのコンポーネントを組み立てた後、 RSTBはLOWのままで、MCUは起動しません。 JTAGデバッガを接続するとRSTBが高負荷になり、MCUを正常にプログラムでき、アプリケーションは通常通り動作します。しかし、JTAGを切断すると RSTBが再び低くなり 、MCUが停止します。 一つ気づいた点として、FS2633のRSTB出力は3.3Vの信号であるのに対し、私の基板ではS32K358のRESETラインは5Vにプルアップされている。この電圧差にもかかわらず、JTAGデバッガが接続されている間は正しく動作します。このリセット電圧レベルやデバッガーがリセットや電源オンの流れに影響を与えている可能性はありますか? この問題は、電源オンシーケンス、リセットタイミング、FS2633の起動設定、あるいはデバッガ関連の挙動に関連している可能性はありますか?同様の問題を経験された方、またはデバッグに関するご提案をお持ちの方はいらっしゃいますか? Re: S32K358 + FS2633: RSTB stays LOW with MCU assembled, but goes HIGH when JTAG is connected FS2633 RSTBを3.3Vにプルアップしてテストしてみて、この問題が解決するかどうか確認した方が良いでしょう。
查看全文
PDB ADC 预触发序列错误恢复 NXP社区的各位好, S32K144 运行时闪存擦除/编程操作后,ADC0/ADC1 中断停止 作为我之前问题的延续,我需要一些关于如何正确恢复 S32K144 上的 PDB ADC 预触发序列错误的说明。 我尝试了以下三种方法,但只有一种方法有效。 方法一(有效): 在执行闪存擦除/编程操作之前,请先停止 PDB0 和 PDB1。 闪存操作完成后,重新启动两个 PDB 并重新启用相应的 ISR。 采用这种方法,不会出现PDB序列错误。 方法2: 闪存擦除/编程操作完成后,我停止并重新启动了 PDB0 和 PDB1。然而,PDB 预触发序列出现错误。然后我尝试通过停止并重新启动 PDB 模块来恢复,但序列错误仍然存在。 方法三: 方法三(无效): 在闪存擦除/编程操作期间,我没有停止或重新启动 PDB0 和 PDB1。相反,操作完成后,产生了一个待处理的 PDB ISR 和一个 ADC ISR 触发信号。 在 PDB ISR 中,我尝试使用以下方法清除序列错误标志: PDB0->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK); 然后执行相应的 ADC ISR,读取 ADC 结果寄存器清除 COCO 标志。我原本期望这样做可以防止进一步的预触发序列错误,但问题仍然存在,这种方法并没有奏效。 我的问题是:一旦触发了 PDB 预触发序列错误,是否有可能在不 RESET 系统的情况下恢复 PDB/ADC 操作并恢复正常触发信号?或者是否需要事先停止并重新启动 PDB,以避免进入不可恢复的状态? Re: PDB ADC pre trigger sequence error recovery 嗨 PetrS, 我尝试了以下方法。 在未停止 PDB 的情况下执行闪存擦除操作后,微控制器收到一个待处理的 ADC ISR 回调。在该回调函数中,读取 ADC 结果寄存器后,我调用以下函数来检查和恢复 PDB 序列错误: ```c void PDB1_check_seq_err(void) { 如果 ((PDB1->CH[0].S & PDB_S_ERR_MASK) != 0) { PDB1->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK); PDB1->SC &= (uint32_t)(~PDB_SC_PDBEN_MASK); PDB1->SC |= (uint32_t)PDB_SC_PDBEN_MASK; PDB1->SC |= (uint32_t)PDB_SC_SWTRIG_MASK; } } void PDB0_check_seq_err(void) { 如果 ((PDB0->CH[0].S & PDB_S_ERR_MASK) != 0) { PDB0->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK); PDB0->SC &= (uint32_t)(~PDB_SC_PDBEN_MASK); PDB0->SC |= (uint32_t)PDB_SC_PDBEN_MASK; PDB0->SC |= (uint32_t)PDB_SC_SWTRIG_MASK; } } ``` 我使用的恢复顺序是: 1. 清除 `ERR` 标志。 2. 停止 PDB。 3. 重新启用并重启 PDB。 通过这种停止和启动序列,一切都恢复正常:后续的预触发发生,ADC ISR 回调正常调用。 然而,我仍然不太明白为什么有必要这样做。参考手册指出,清除“ERR”条件并读取ADC结果寄存器(这将清除“COCO”)应该可以释放锁定。就我而言,仅靠这一点似乎还不够,需要执行 PDB 停止/启动序列才能恢复。 另外,我观察到 `PDBn->SC |= PDB_SC_SWTRIG_MASK` 并不是严格必需的。即使没有发出软件触发信号,PDB 重启后,锁定也会被释放,ADC ISR 也会再次开始执行。 请问为什么在这种情况下需要停止并重新启动 PDB,即使 RM 指示清除 `ERR` 和 `COCO` 应该可以释放锁? Re: PDB ADC pre trigger sequence error recovery 您好, 仅清除 PDB_S_ERR 通常不足以从触发信号前序列错误中恢复,因为 ADC/PDB 序列可能已经失去同步。根据您的测试结果,在刷写操作之前停止 PDB,然后在刷写操作之后重新启动 PDB,似乎是防止出现这种情况的最可靠方法。 如果在发生错误后尝试恢复,我建议确保 PDB 和 ADC 的状态完全重新同步。这可能包括禁用 PDB、清除待处理的 PDB 状态标志、确保所有待处理的 ADC 转换结果都已读取(COCO 已清除)、重新启用 PDB,以及在执行触发信号恢复之前根据需要重新加载配置。 根据 RM 的说法,当相应的 COCO 标志被设置、预触发被禁用或 PDB 被禁用时,预触发锁将被释放,因此完整的 PDB 禁用/启用序列也可能值得研究。 BR,彼得
查看全文
LX2160A 对 FlexSPI DDR/DTR 模式的支持 - 需要 DQS 说明 你好, 我们正在开发 LX2160A-RDB 板的 FlexSPI 驱动程序,并且对 DDR(八进制 DTR)模式支持有一个疑问。 我们的板上有两个 MT35XU512ABA 闪存芯片连接到 FlexSPI 控制器。从板原理图可以确认,XSPI_A_DQS 信号从闪存(引脚 C3)路由到 LX2160A。 处理器(引脚 E23)。 但是,当我们尝试使用 DTR 模式时,闪存读取返回无效数据(全为零)。SDR八进制模式(1-8-8)在各种频率下都能正常工作。 我们还注意到,在 Linux 内核中,LX2160A FlexSPI 驱动程序设置了 FSPI_QUIRK_DISABLE_DTR。 https://lists.infradead.org/pipermail/linux-mtd/2022-July/094127.html 请问您能否澄清一下: 1. LX2160A FlexSPI 控制器是否支持 DTR/DDR 模式下的基于 DQS 的数据采样,还是这是已知的芯片限制? 2. 如果芯片不支持 DQS,那么 RDB 板上的 XSPI_A_DQS 引脚布线的目的是什么? 3. 是否有任何配置或勘误表可以让 DTR 模式在 LX2160A 上运行? 电路板:LX2160A-RDB Rev B 闪存:MT35XU512ABA(*2,八进制) 参考手册:LX2160A 参考设计板参考手册,修订版 5,2021 年 9 月 28 日 云实验室 在线调试 在线实验室 虚拟测试 Re: FlexSPI DDR/DTR mode support on LX2160A - DQS clarification needed MT35XU512ABA 将具有特定的 SPI 协议,称为 Xccela。不确定LX 2160A是否支持。 Re: FlexSPI DDR/DTR mode support on LX2160A - DQS clarification needed 你好, 实际的解决方法是:除非 NXP 确认有针对特定芯片版本的变通方案,否则 Linux/LSDK 中对 LX2160A-RDB 上的八进制 DTR 不予支持。最有力的实现证据是您找到的 NXP Linux 补丁:它为 LX2160A 添加了 FSPI_QUIRK_DISABLE_DTR 因为“lx2160a 没有实现 DQS”,并指出这会导致八进制 DTR 模式下的闪存探测失败。 针对您的具体问题: LX2160A FlexSPI 是否支持基于 DQS 的 DTR/DDR 采样? 参考手册将 FlexSPI IP 描述为具有 DQS/读取选通采样模式: MCR0[RXCLKSRC] = 0x3 选择“闪存提供的读取选通和来自 DQS 焊盘的输入”,并且输入时序部分明确描述了使用闪存提供的读取选通进行采样。然而,LX2160A 的 Linux 平台数据明确禁用了 DTR,因为该平台“不实现 DQS”。因此,我不会依赖通用的 FlexSPI IP 描述来证明 LX2160A 芯片可以使用外部 DQS 进行八进制 DTR。 为什么 XSPI_A_DQS 被路由到 LX2160A-RDB? DQS 引脚不仅仅是闪光灯提供的读取频闪信号。该手册将 A_DQS 描述为具有多种可能功能的 I/O:外部读取选通、延迟信息和环回虚拟读取选通;它还指出,可以在此引脚上进行板级加载,以补偿环回模式下的 DATA/SCLK 加载。同一个 FlexSPI 模块还使用 DQS/RWDS 作为某些写入操作的写掩码相关信号。因此,RDB 布线与 FlexSPI 引脚/功能集和板兼容性一致,但这本身并不能证明 LX2160A 支持基于外部 DQS 的八进制 DTR 读取。 LX2160A 是否有任何配置或勘误表可以启用 DTR? 我找到了 DQS 模式的文档配置 MCR0[RXCLKSRC] = 0x3 ,当使用闪存提供的读取选通时,DLL 设置如下: SLVDLYTARGET=0xF , DLLEN=1 , OVRDEN=0 ;对于低于 100 MHz 的串行根时钟,手册建议使用 DLL 覆盖模式, OVRDEN=1 ,并调整 OVRDVAL ,其中 N = 18 是一个推荐值,可能需要调整。但LX2160A特有的Linux问题指出,由于LX2160A未实现DQS,因此DTR功能被禁用。我查阅了LX2160A参考手册/数据手册、RDB参考手册、NXP/Linux补丁文本以及公开的勘误表,均未找到任何关于重新启用DQS/DTR的LX2160A勘误或已记录的解决方法。 https://lists.infradead.org/pipermail/linux-mtd/2022-July/094127.html 推荐的驱动程序位置:对 LX2160A 保持 FSPI_QUIRK_DISABLE_DTR ,并使用 SDR 八进制 1-8-8 。您的症状——SDR 八进制工作,DTR 读取返回零——与上游决定阻止此 SoC 上的 DTR 一致,而不是简单的板布线问题。 此致
查看全文
纽约州纽约市离婚律师 纽约离婚律师专门从事家庭法,为寻求离婚、分居或解决相关问题的个人提供专业代理服务。他们的执业领域包括离婚、分居协议、子女监护权、探视权、子女抚养费、配偶赡养费、财产分割、婚前和婚后协议、亲子鉴定纠纷以及现有协议的修改。一名优秀的离婚律师应该具备纽约州家庭法方面的经验、较强的谈判和诉讼技巧、同理心、注重细节,以及对当地法院和程序的了解。聘请离婚律师的好处包括保护权利和利益、在复杂的过程中提供专家指导、个性化代理、提高获得有利结果的可能性以及减轻压力和情感负担。寻找合格的纽约州离婚律师的资源:纽约州律师协会、美国婚姻律师学会和国家州法院中心。 Re: new york ny divorce lawyer 严重的犬只袭击事件可能使受害者面临身体伤害、医疗费用以及对未来的不确定性。在德克萨斯州提起狗咬伤索赔诉讼可能有助于获得治疗费用、工资损失、疼痛以及与该事件相关的其他损失的赔偿。德克萨斯州经验丰富的狗咬伤律师可以审查袭击事件的情况,收集佐证材料,并指导受害者完成法律程序。无论事件发生在公共场所还是私人场所,了解您的权利都是保护自身利益的重要一步。对于那些寻求本地法律援助的人来说,阿灵顿的狗咬伤律师可以提供根据案件具体情况量身定制的法律支持。值得信赖的德克萨斯州人身伤害律师致力于帮助受害者根据德克萨斯州法律获得他们应得的赔偿。
查看全文
S32K144チップにはクロック構成の問題があり、クロックを変更するとタイミング周期が変わってしまう。 S32K144の開発中に、以下の問題に遭遇しました。 Ni__0-1782181934609.png 初期化タイマーの割り込みオーバーフロー期間は1秒に設定する必要があります。 前提として、私のクロック設定は8MHzです。 Ni__1-1782182016343.png Ni__2-1782182026827.png しかし、時計を20Mの時計に変えた後… Ni__3-1782182078529.png Ni__4-1782182086180.png タイマーのオーバーフロー期間が1秒ではなく、400ミリ秒になっていることに気づきました。 しかし、タイマーのクロック設定は依然として8MHzの内部クロックに設定されたままです。 PCC->PCCn[PCC_FTM1_INDEX] |= PCC_PCCn_PCS(0x01) /* クロックソース=1、8 MHz SIRCDIV1_CLK */ | PCC_PCCn_CGC_MASK; /* FTMレジスタのクロックを有効にする */ この問題の原因となっている設定上の問題が何なのか、私には分かりません。 Re: S32K144芯片的时钟配置问题,更改时钟后定时周期出现变化 ハイ 次の S32K1 RM の表 27-9 を参照してください。peripheral module clocking (continued),FTM具体選択哪个时钟源需要查看FTMn_SC[CLKS]和29.6.17 PCC FTM1 Register (PCC_FTM1)的PCS位。 Table 27-9. Peripheral module clocking FTM.png プロセッサ エキスパートがコンフィギュレーションを生成し、ベアメタル モードでレジスタを直接操作しました。SDK サイトを使用した API が原因でベアメタル プログラムがクラッシュしたかどうかはわかりません。 さらに、ProcessorExpert 搭載 SDK の API を使用する場合は、ベアメタルの直接操作レジスタの構築リファレンス S32K144_Project_FTM サンプル ftm_periodic_interrupt_s32k144 を参照してください。 よろしくお願いいたします ロビン
查看全文
FS26 Amux 传感问题 我尝试在将BAT 感知电压连接到AMUX 引脚后测量该引脚上的电压。我已经验证了所有相关的寄存器值, FS_STATES寄存器报告设备处于正常模式。然而,AMUX 引脚持续输出 0 V,我的 12 位 ADC 读数始终为 0。我的代码以S32K3xx 参考示例之一为基础(已附上),但 AMUX 测量功能并未按预期工作。请查一下。 Re: FS26 Amux sensing issue 您好, 感谢您分享代码和详细信息。请您核对以下内容: - 写入后读取 M_AMUX_CTRL 寄存器,并确认 AMUX_EN = 1 且 AMUX[4:0] = 0x16(已选择 BATSENSE)。 - 请同时确认 SPI 响应指示 M_AVAL = 1,这意味着主状态机处于正常模式。 - 硬件方面,请确认 BATSENSE 引脚是否有预期的电压,以及 AMUX 引脚是否正确连接到 ADC 输入。   BRs,托马斯 Re: FS26 Amux sensing issue M_AMUX_CTRL 寄存器配置为 M_AMUX_EN | M_AMUX_BATSENSE | M_AMUX_DIV_0,并通过回读验证为 0x56。这证实了模拟多路复用器处于活动状态,并正确地路由了 12V 电池感应输入。   但是,SPI 设备状态 (u8DeviceStatus) 读取结果为 0xCA。由于最高有效位已设置(sbc_fs26_RxFrameType.u8DeviceStatus & 0x80 == 1),因此全局故障保护故障处于活动状态。此外,FS_STATES 寄存器返回 11,证明设备卡在 INIT_FS(初始化故障保护)状态。 Re: FS26 Amux sensing issue 你好, 您的回读结果确认 AMUX 配置正确,但设备卡在 INIT_FS 中。 为解决此问题,请按照AN13850 (需要签署保密协议的安全文件)第 6.1 节和第 6.2 节中描述的初始化和监视程序序列进行操作: 上电或 RESET 后,按照 6.1 节所述配置所有必需的 FS_I_xxx 和 FS_I_NOT_xxx 寄存器。 在 256 毫秒的 INIT_FS 窗口内执行一次良好的看门狗刷新,以结束初始化阶段。 一旦功能安全输出解除,设备将进入正常模式,AMUX 测量功能将按预期运行。 BRs,托马斯 Re: FS26 Amux sensing issue 感谢您的支持。 我的 AMUX 没有正确启用,所以它没有将选定的电压路由到 AMUX 引脚。非常感谢您提供的初始化序列——它解决了这个问题。我还把看门狗周期配置为 256,现在设备如预期那样保持在正常状态。
查看全文
GPIO_EMC_B2_18をFLEXSPI1_A_DQSとして設定し、クロック周波数を133 MHzに設定するにはどうすればいいですか? こんにちは、 i.MX RT1175のGPIO_EMC_B2_18をFLEXSPI1_A_DQSとして設定し、クロック周波数を133MHzに設定したい。 GPIO_EMC_B2_18起動時にFLEXSPI1_A_DQSに設定できないことは理解しています。 そのため、起動時に60MHzで動作させて、アプリケーション内で133MHzに変更しようとしていますが、うまくいきません。 私はevkbmimxrt1170_flexspi_nor_polling_transferプロジェクトを使用しており、`flexspi_nor_flash_ops.c`内の`flexspi_nor_flash_init()`の関連セクションを変更しました。 「`」 IOMUXC_SetPinMux(IOMUXC_GPIO_EMC_B2_18_FLEXSPI1_A_DQS, 1U); IOMUXC_SetPinConfig(IOMUXC_GPIO_EMC_B2_18_FLEXSPI1_A_DQS, 0x0AU); CLOCK_SetRootClockDiv(kCLOCK_Root_Flexspi1, 4); CLOCK_SetRootClockMux(kCLOCK_Root_Flexspi1, 5); config.rxSampleClock= kFLEXSPI_ReadSampleClkLoopbackFromDqsPad; 「`」 クロック周波数を133MHzに設定すると、システムがフリーズします。 「`」 CLOCK_SetRootClockDiv(kCLOCK_Root_Flexspi1, 5); CLOCK_SetRootClockMux(kCLOCK_Root_Flexspi1, 5); 「`」 クロック周波数を105MHzに設定すると動作します。 GPIO_EMC_B2_18をFLEXSPI1_A_DQSに設定し、クロック周波数を133 MHzに設定するにはどうすればいいですか? Re: How can I configure GPIO_EMC_B2_18 as FLEXSPI1_A_DQS and set the clock frequency to 133 MHz? こんにちは、@mayliu1 さん。 ご返信ありがとうございます。 セカンダリpingグループは100MHzでしか動作しないかもしれませんが、私はプライマリpingグループを使い、DQSだけをGPIO_EMC_B2_18に変更する予定です。理由は、USDHC2_CMD に GPIO_SD_B2_05 を使用しているためです。 ピン構成 FLEXSPI1_A_SS0_B GPIO_SD_B2_06 FLEXSPI1_A_SCLK GPIO_SD_B2_07 FLEXSPI1_A_DATA0 GPIO_SD_B2_08 FLEXSPI1_A_DATA1 GPIO_SD_B2_09 FLEXSPI1_A_DATA2 GPIO_SD_B2_10 FLEXSPI1_A_DATA3 GPIO_SD_B2_11 FLEXSPI1_A_DQS GPIO_SD_B2_05(ブーツ) アプリケーションでは、FLEXSPI1_A_DQSのみがGPIO_EMC_B2_18に変更されます。 FLEXSPI1_A_DQS GPIO_EMC_B2_18 テストとして、EVKのクロック周波数を60MHz(ブート時)から133MHzに変更しましたが、FLEXSPI1_A_DQSは変更せず、GPIO_SD_B2_05に設定したままにしました。すると、同じようにハングアップしました。 xip 設定が .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally に設定されているため、それをkFlexSPIReadSampleClk_LoopbackFromDqsPadに変更したところ、133MHzで動作させることができました。 次に、DQSをGPIO_EMC_B2_18に変更してみたところ、133MHzで動作させることができました。 このやり方は受け入れられるだろうか? また、起動時にはGPIO_SD_B2_05はフローティング状態ではありません。`kFlexSPIReadSampleClk_LoopbackFromDqsPad`に設定して60MHzで実行しても問題ありませんか? Re: How can I configure GPIO_EMC_B2_18 as FLEXSPI1_A_DQS and set the clock frequency to 133 MHz? こんにちは@Shuhei_Dさん 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 詳細については、以下の記事をご参照ください。 https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/RT-1176-FlexSPI-RW-frequency-DQS/mp/1871808 RT1170リファレンスマニュアルによると、セカンダリピングループを使用した場合、FlexSPIフラッシュの最大対応周波数は100 MHzです。 プロジェクトの構成を確認し、上記のリンクで説明されているシナリオに合致しているか確認していただけますか? お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: How can I configure GPIO_EMC_B2_18 as FLEXSPI1_A_DQS and set the clock frequency to 133 MHz? お返事ありがとうございます。 回路図を確認したところ、GPIO_EMC_B2_18がフローティング状態になっていることがわかりました。 Re: How can I configure GPIO_EMC_B2_18 as FLEXSPI1_A_DQS and set the clock frequency to 133 MHz? NORフラッシュの外付けを駆動するために、SPIのクロック周波数を60MHzから133MHzに変えたいようですね。しかし105MHzなら問題なさそうなので、SPI高周波数で信号の整合性をレイアウト側で確認する必要があるかもしれません。回路図を確認しますか? Re: How can I configure GPIO_EMC_B2_18 as FLEXSPI1_A_DQS and set the clock frequency to 133 MHz? こんにちは@Shuhei_Dさん ご辛抱いただきありがとうございます。 ご質問内容を再度確認しました。 プライマリDQS PINを使用し、セカンダリDQSオプションは使用しないでください。 mayliu1_0-1782368272303.png あなたの場合、もし主DQSピンがすでに別の機能に使われている場合、以下の構成を適用できます。ただし、この設定は最大60MHzまでしかサポートされていないことにご注意ください。 mayliu1_1-1782368409020.png お役に立てれば幸いです。 よろしくお願いいたします。 5月
查看全文
ISP support for iMX95 FRDM Evaluation kit Hi Team, I am trying to port a Bayer sensor on the i.MX95 FRDM platform. Following the software setup guide below, I was able to connect and stream video using the NXP-supported OS08A20 camera module which was provided in the NXP website. Now, I would like to port and stream a different Bayer sensor. Is there any documentation available that explains: Where to obtain the libcamera source code and how to build it for the i.MX95 platform? How to generate ISP-specific YAML and configuration files for a new Bayer sensor? What camera driver parameters and controls are required to support a Bayer sensor on the i.MX95 FRDM platform? The complete software flow for integrating a new Bayer sensor with the NXP ISP pipeline? Can you please let me know at the earliest. Thanks Re: ISP support for iMX95 FRDM Evaluation kit Hello, Please refer to the following guide: https://www.nxp.com/docs/en/user-guide/UG10215.pdf Best regards/Saludos, Aldo.
查看全文
Debug application started by the MCUBOOT Dear Everyone, the board we use is IMXRT1176. I would like to debug my application which is started by mcuboot. I would like the debugger to flash a signed application and debug it afterwards. Let me show you what i did: 1. Original build produced me an app.elf 2. I converted an app.elf to app.bin and singed it with imgtool to create app_signed.bin 3. I used arm-none-eabi-objcopy to wrap app_signed.bin into app_signed.bin.elf 4. I used this lanuch.json configuration ``` { "type": "mcuxpresso-debug", "name": "Debug bootloader app", "request": "launch", "cwd": "${workspaceFolder}", "executable": " /app.elf", "isAttach": false, "probeType": "LinkServer", "stopAtSymbol": "main", "skipBuildBeforeDebug": true, "extraSymbolFiles": [     " /app.elf",     " /bootloader.elf", ], "postLaunchCommands": [     "load /app_signed.bin.elf 0x30100000" ], "gdbInitCommands": [    "set remotetimeout 600",     "set debug-file-directory",     "set non-stop off", ], "gdbServerConfigs": {     "linkserver": {          "device": "MIMXRT1176xxxxx:MIMXRT1170-EVKB",          "core": "cm7", }, "segger": {}, "pemicro": {} }, }, ``` It seems to work, meaning i can debug both bootloader and app, but it feels like a hack. What I don't like the most is that flash is written twice. Once for executable where we write unsigned binary and one for load where we write signed binary (which has the same core code obviously). Could you please tell me if i missed something obvious? Do you think there is a cleaner way to achieve that. Just as an info, I know how to attach to already flashed image, the process above is more about convenience to start debugging in one step, I mention this to express what my goal is. Thanks a lot in advance for any help and suggestions! Best Regards, Jakub Re: Debug application started by the MCUBOOT Hello @jslota13245, There are currently no defined steps that combine flashing and debugging a signed image into a single workflow, as these are typically handled as separate processes. In general, you would first flash the signed image onto the device and then attach the debugger afterwards. As a reference, you may find it helpful to review the "Running the demo" section of the ota_mcuboot_basic example, which demonstrates two different approaches for flashing a signed image that could be adapted to your setup. Additionally, the "Transferring data" to the flash memory section provides an overview of the available tools that can be used for the flashing process. On the other hand, could you please clarify the reason for converting the signed image into a .bin.elf file? Also, could you confirm if you followed a guide for this process? BR Habib Re: Debug application started by the MCUBOOT Hello Habib! thank you for the reply. To answer your question. I followed this guide for flashing multiple binaries at the start-up. We use mcuxpresso for vs-code instead of IDE but the premise should be the same: https://mcuoneclipse.com/2022/11/01/loading-multiple-binary-files-with-gdb/ The idea here is that the elf file has information to debug a signed binary, as signed binary is just a binary with header and trailer attached. If the .elf file was generated with this layout in mind it should work as intended.  For future reference, approach i suggested in my original post doesn't work too well as debugger gets stuck on non-existing 0x00000 breakpoints while the CPU is still running so i suspect no real crash has occurred. There is clearly some configuration/integration debugger problem here but I can't point exactly where. Did you encounter such behaviour by any chance? As for your suggested approach, I found this section: ``` programing signed application image to the primary application partition using an external tool (direct method) jump-starting the application by debugger, performing an image update with the signed image, resetting the board and letting the bootloader to perform the update (indirect method) The latter method is used in the following step-by-step description: Open the demo project and build it. Known issue: MDK linker issues warning about unused boot_hdr sections. This does not affect the functionality of the example. Prepare signed image of the application from raw binary as described in the readme of mcuboot_opensource SDK example. In case of MCUXpresso raw binary may not be generated automatically. Use binary tools after right clicking Binaries/.axf file in the project tree to generate it manually. Launch the debugger in your IDE to jump-start the application. In case of MCUXpresso IDE the execution stalls in an endless loop in the bootloader. Pause the debugging and use debugger console and issue command jump ResetISR.  ``` But I'm a bit lost on what do i need to do with the extension for VS-code - I don't have ide backend unfortunately. Could you please help me by answering the questions below? Let's assume i do have a signed binary and original elf file with symbols.  1. How can debugger kick start signed image? 2. How can debugger kick start it without flashing it first? The point 1 explicitly states to flash it with some tool - i assume point 2 does something else?.  3. The debugger can't flash just base elf file as it'll be discarded by the mcuboot as it doesn't have mcuboot header and a trailer. 4. When point 2.3 states 'Launch the debugger in your IDE to jump-start the application' - does it mean the debugger flashes something? Or does it attach to already flashed image? Thanks in advance for your help and time 🙂 Best Regards, Jakub Re: Debug application started by the MCUBOOT Hello @jslota13245, When you mention "I don't have ide backend unfortunately" I understand this may refer to limited familiarity with the MCUXpresso extension for VS Code, is my understanding correct? If so, I recommend reviewing the chapter "Explore Extension" in the official documentation for the extension, as it provides a helpful overview of its features. Regarding your questions, when you start a debug session, the tool by default programs the generated image into flash and then attaches the debugger, which automatically jump to the main function. this is described in the "starting a debug sesion" section, inside this page you will find more information about the functionality of the debug in the extension.  I can also, suggest you review the chapter "debug a project" which shows the steps to debug your code. I highly recommend first validating and debugging your application without MCUboot or image signing and only introducing MCUboot once your application is fully tested. For make this process we strongly recommend using MCUxpresso Secure Provisioning Tool, which has the capabilities to manage security features such as key generation and image signing for MCUboot, which is why this is standard tool to handle applications just like this one. You can find more information about how sign image and flash your MCUboot in the chapter 7.6.2 " Steps to start MCUboot with such a processor manually"of the Secure Provisioning Tool User Guide 26.03. On the other hand, when integrating MCUboot, ensure that it is placed in a dedicated flash region that is not overwritten by other images, the mcuboot_opensource_cm7 example offers an alternative of how place each image:   | Region         | From       | To         | Size   | |----------------|------------|------------|--------| | MCUboot code   | 0x30000000 | 0x3003FFFF | 256kB  | | Primary slot   | 0x30040000 | 0x3023FFFF | 2048kB | | Secondary slot | 0x30240000 | 0x3043FFFF | 2048kB | You should first program the MCUboot image into its dedicated flash region, and then place the signed application image into the primary or secondary slot. The MCUXpresso Secure Provisioning Tool can facilitate this process by handling both, program the bootloader and program the image within a single workflow, as described in section 7.6.2 of the user guide I previously shared. BR Habib Re: Debug application started by the MCUBOOT I will read about about it. Thanks a lot! 🙂 Re: Debug application started by the MCUBOOT Some comments regarding the debug configuration from your first post: 1. MCUXpresso for VS Code extension relies on "runners.yaml" from Zephyr (or MCUXpresso SDK). Usually, there could be separate values for ELF/BIN files. In your case, you should probably have the "bin_file" property pointing to your "app_signed.bin" (see screenshot below). Important note: if ELF & BIN are pointing to the same file (e.g. "app", but file extensions differ), there's the "executableLoadTypePriority" property inside the debug configuration that controls what is actually loaded on target. 2. If you have the "runners.yaml" file defined as described above, you will not need to specify anything in the MCUXpresso debug configuration (see screenshot below). 3. If you have the "runners" file defined as described above, the ELF file from "runners" will be used by the extension for loading debug symbols only and the BIN file to load app on target. As a result, no "postLaunchCommands" property needed. 4. The "bootloader.elf" must still be added in the "extraLoadFiles" property, but you won't need "app.elf" alongside. If the "runners.yaml" is not defined as above, you can have something like: "executable": {   "elf": ".../app.elf",   "binary": {    "path": ".../app_signed.elf",    "address": 256   } } The two approaches should have similar outcome. AdrianOltean_0-1783336918679.png Re: Debug application started by the MCUBOOT Hi Adrian, Sounds very promising 🙂 I'll give it a try, thank you very much - for both sharing details about the extension and for your suggestions! Best Regards, Jakub
查看全文
S32K3の駆動力は高い S32K3XXのリファレンス・マニュアルには「ドライブ強度の有効化」ビットについて書かれていますが、その意味を明確に定義しているようには見えません。私が見つけた最も近い参考文献は、特定のピンがサポートする最大周波数と相関しているようです(S32K3XXRM/セクション4.4.1の42ページ)。 「drive-strength」を有効にすべきか否かを判断する上で、最大消費電流値やその他の注意点に関して、何か明確な規定はありますか? Re: High Drive Strength on S32K3 GPIO規格:最大10MHzのスイッチングに対応。高駆動強度には対応していません。スルーレート制御はサポートされていません。 — GPIO-Standard plus:最大25 MHzへの切り替え 高い駆動強度をサポートします。スルーレート制御はサポートされていません。 — GPIO-Medium:最大50 MHzまでの切り替えで高いドライブ強度をサポートします。スルーレート制御をサポートします。 — GPIO-Fast:最大120 MHzへの切り替え 高いドライブ強度をサポートします。スルーレート制御をサポートします。 Re: High Drive Strength on S32K3 はい、それはまさに私が質問で引用した箇所の文章です。それではなぜ「ドライブ強度」を有効にするべきか、あるいは有効でないかはわかりません。単に一部のピンがそれをサポートしていること、そして一部の切り替え速度がそれに関連していることを示しているだけです。 もしこれでLEDを駆動する場合、より多くの電流を流すことができるでしょうか?どれくらい最新の情報ですか? これは純粋にスルーレートの変更なのでしょうか? ピンがサポートしているなら、有効にしない理由はありますか?それを有効にすると、チップの放熱量は増えますか? Re: High Drive Strength on S32K3 S32K39x、S32K37x、S32K36xマイクロコントローラのハードウェア設計ガイドライン Re: High Drive Strength on S32K3 ハイ S32K3XXリファレンスマニュアル(S32K3XXRM)では、パッドタイプ「GPIO-Standard」は高駆動強度をサポートしない一方、「GPIO-Standard Plus」、「GPIO-Medium」、「GPIO-Fast」は高駆動力をサポートしていると記載されています。 GPIOパッドタイプについては、S32K3XXRMに付属のExcel添付ファイルS32K344_S32K324_S32K314_IOMUX.xlsxのS32K344_IO信号テーブル、特に列Hを参照してください。 drive-strength high current Pad Type.png よろしくお願いします、 ロビン ------------------------------------------------------------------------------- 注記: この投稿があなたの質問への回答になっている場合は、「解決策として承認」ボタンをクリックしてください。ありがとう! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: High Drive Strength on S32K3 前の投稿者にも言いましたが、どのピンが「高い駆動強度」をサポートしているかは分かっていますが、それが問題ではありません! しかし幸いなことに、背景には関連する情報が詰まっていました。S32K3xx.pdf には、表27。GPIOのDC電気仕様には、私が求めているものが含まれているようです。 これは、ピンの出力電流を2倍にして、「DSE = 0」と「DSE = 1」を切り替えるようにしているようです。 Screenshot From 2026-07-06 09-18-58.png Screenshot From 2026-07-06 09-18-48.png
查看全文
S32K324のVREFH こんにちは、NXP チームの皆様、 回路には3.3Vで動作するS32K324マイクロコントローラを使っています。マイクロコントローラ内のVREFHピン自体は3.3V(VDD_HV_A / VDD_HV_B)に接続されています。データシートに、VREFH電圧レベルに関する注記がありました。 hemanths_0-1688361073670.png しかし、ハードウェアデザインガイドラインのドキュメントにはこのコメントは記載されていません。 hemanths_1-1688361175410.png どなたか、データシートに記載されているノートの意義について説明してもらえますか? ありがとうございます。 ヘマント Re: VREFH for S32K324 こんにちは、 @JulesW さん。 データシート(表3、動作条件)によると、VREFHは最低2.97Vに制限されているため、これは仕様外となります。 BR、ダニエル Re: VREFH for S32K324 VREHがVDD_HV_Aよりもはるかに低い場合、例えばVDD = 3.3Vの場合にVREFH = 2.5Vとなる場合はどうなるでしょうか? Re: VREFH for S32K324 ADCの結果は飽和状態になるだろう。 注入電流は、ピンあたり3mAに制限する必要があります。 danielmartynek_0-1688384914242.png danielmartynek_1-1688385147391.png BR、ダニエル Re: VREFH for S32K324 こんにちは、ダニエルさん。 ご回答ありがとうございます。 ADCの入力電圧がADCのVREFHよりも大きい場合、どうなりますか?マイクロコントローラのADCに過電圧保護や飽和機構があるかどうか? Re: VREFH for S32K324 こんにちは、ヘマントさん。 VREFH参照は必ずしもVDD_HV_A/VDD_HV_Bにコネクテッドする必要はありません。 しかし基準はVDD_HV_Aにクランプされるため、電圧はVDD_HV_A + 0.1Vを超えてはならず、0.1VはRF信号専用です。 HWDGの改訂版においてC、仕様書も見つけることができます: danielmartynek_0-1688380987606.png よろしくお願いいたします。 ダニエル
查看全文
PXIコントローラのMPU選び方 オープンソースのPXIシャーシコントローラを作りたいと思っています(ご存じない方のために説明すると、基本的にArm SBCで、PCIe経由でバックプレーンに接続し、ペリフェラルのPXIモジュールも同じですが、RCではなくPCIe EPが付いています) 例えば、Linux配信を動かせるMPUが必要です。Ubuntuはグラフィックモードで、まずまずのパフォーマンスを保ち、例えば特殊なソフトウェアが動作しているはずです。LabVIEWおよびカスタムペリフェラルモジュールはユーティリティを制御し、1秒あたり数GBの生データを処理します。PXI仕様で規定されているように、少なくとも2つの独立したPCIe RCを備えている必要があり、速度が速ければ速いほど良い。速度が十分であれば、例えばRF AWGでDACに生データを連続的に供給し、AWGのRAMサイズに制限されません。また、LPDDR4を大量に接続できる可能性も面白いです。典型的な32ビットバスだけでなく、64+も対応可能です。 新しいTI Am69aはかっこいいようですが、かなり高くなそうですし、しかも非常に新しいので、完全なエラッタやソフトウェアの例、ドライバなどはありません。ハードウェア開発者で趣味でコーディングしている私には難しすぎると思います もう一つの方法はRockchip RK3588で、より手頃で古いですが、PCIeが遅すぎて、Gen 3の2台だけです。確かに受け入れられるけど...もしかしたら、もっと良いアイデアがあるか、最近似たようなことをしたことがあるかもしれませんね?ぜひ聞かせていただきたいです 🙂 Re: Choosing an MPU for PXI controller LS1046AまたはLX2160Aをご検討ください。しかし、これらのSoCはGUI用のグラフィックスエンジンを統合していないため、外部ソリューション(例えばリモートGUIや個別GPUなど)が必要です。 ありがとうございます。
查看全文
TRGMUX 技术支持 - MCXE316 我正在尝试使用 TRGMUX 方法将比较器 LPCMP0 的输出路由到 emios0_CH7 的输入(配置为输入捕获)。我正在使用 MCXE316 设备。我的问题之一在于理解输入/输出以及弄明白相关术语,而第二个问题我认为是 PERI_TRGMUX.h 中的一个错误。文件。 我将 emiOS0 通道 7 配置为简单的输入捕获,分配给物理引脚后可以正常工作。但是,我希望改用 LPCMP0 比较器的输出来触发输入捕获。因此,我应该能够让 TRGMUX 将比较器的输出路由到 EMIOS0_7 的输入捕获的输入。 我看了参考手册所附的 MCXE31_TRGMUX_connectivity.xlsx 文件,在左边看到 " 输入数字 ",我假设这是输入 TRGMUX 的。我看到那里列出了 LPCMP_0_COUT,输入数为 5,这应该就是我想要的。在顶部,我看到"、EMIOS_0_ipp_ind_emios_ch[7]、" ,并且在其上方看到输出寄存器编号为9。我还注意到,第5、6和9频道也显示了同样的数字。 那么,我的第一个问题 —— 如何告诉 TRGMUX LPCMP0 触发信号输出进入通道 7 而不是 5、6 或 9?我知道 TRGMUX 寄存器的内部有 SEL0、SEL1、SEL2 和 SEL3 —— 我是否要用其中一个来选择信道?如果是这样,这是如何映射的(例如 SEL0 对应通道 5 等),还是有其他映射方式,抑或根本没有映射?我查阅了说明书,但没找到相关内容。 我推测 SEL3 对应第 7 通道(仅作测试),于是尝试使用 SDK 中的 TRGMUX 方法——以下是我的调用序列:   TRGMUX_SetTriggerSource(TRGMUX, kTRGMUX_Emios0_1, kTRGMUX_TriggerInput2, kTRGMUX_SourceLpcmp0 ); 以 TRGMUX 为寄存器基础,ktrgmux_emios0_1 是 emiOS0 的 TRGMUX 寄存器(定义值为 9),ktrgmux_triggerInput2 是寄存器的 SEL2 输入,ktrgmux_sourcelPCMP0 是触发器的来源(定义值为 5)。 问题在于,该例程会在该方法内部抛出严重错误。以下是该方法的实际 SDK 代码: status_t TRGMUX_SetTriggerSource(TRGMUX_Type *base, uint32_t index, trgmux_trigger_input_t input, uint32_t trigger_src) { uint32_t value; status_t status;   value = base->TRGCFG[index]; if (0U != (value& TRGMUX_TRGCFG_LK_MASK)) { status = kStatus_TRGMUX_Locked; } else { /* 由于 TRGCFG 寄存器中的所有 SEL 位字段长度相同,因此使用 SEL0 的掩码来 访问其他 SEL * 位字段。*/ value = (value& ~((uint32_t)TRGMUX_TRGCFG_SEL0_MASK<< (uint32_t)input)) | ((trigger_src& (uint32_t)TRGMUX_TRGCFG_SEL0_MASK)<< (uint32_t)input); base->TRGCFG[index] = value;    status = kStatus_Success; }   返回状态; } 该例程在第一行发生崩溃: value=base->TRGCFG[index]; 查看调试输出后,似乎 TRGCFG 数组从未被初始化——该变量在 PERI_TRGMUX.h 中定义其结构如下: /** TRGMUX - 寄存器数组大小 */ #define TRGMUX_TRGCFG_COUNT 40u /** TRGMUX - 寄存器布局类型定义 */ typedef struct { __IO uint32_t TRGCFG[TRGMUX_TRGCFG_COUNT]; /**< TRGMUX ADC12_0 寄存器..TRGMUX CM7_RXEV 寄存器,数组偏移量:0x0,数组步长:0x4,有效索引:[0-1, 3, 6-18, 21-39] */ } TRGMUX_Type; 我就是找不到TRGCFG到底是在哪里定义的。在调试器中,整个数组的40个元素都被设置为199661,这显然是垃圾数据。我正在访问第 9 个元素(索引为 9)。 那么我的第二个问题是:我使用这种方法是否正确,我的假设是否合理,还是SDK例程本身存在问题? 电路板设计 启动 ROM | 启动配置 | 闪存 时钟|计时器 Re: TRGMUX Assistance - MCXE316 你好@brucebowling  谢谢你的帖子! 您对 TRGMUX SELx 工作原理的理解是正确的:EMIOS0_0 对应第 1 至 4 通道,EMIOS0_1 对应第 5 至 7 通道以及第 9 通道,如 TRGMUX_connectivity.xlsx 所示,第 0 和第 8 通道不可用。  此外, 我这边成功复现了该问题。我将进行内部核查,并提供任何有助于解决此问题的相关信息。 Re: TRGMUX Assistance - MCXE316 我想了解一下关于 SDK 和 TRGMUX 函数是否有任何新的反馈? 由于 TRGMUX 每个外设只有一个寄存器,我尝试使用以下一行代码直接写入: *(volatile uint32_t *)0x40080024UL = 0x00050000UL; 根据 RM,TRGMUX 基地址为 0x4008_000,TRGMUX_eMIOS0_1 寄存器偏移量为 0x24,绝对地址为 0x40080024。LPCMP0_COUT 的 SELx 字段为 0x05 - 我将其上移到 SEL2 位位置(位 16:23)。锁定位应为 0(从 RESET 开始,即解锁状态),我将其保持解锁状态。 这一行代码每次都会导致硬故障崩溃(故障不精确)。我尝试修改其他 SELx 位置,但仍然崩溃。我尝试在设置 eMIOS 和 LPCMP 之前分配此权限,也尝试在完成外围设备设置之后分配,但每次都会崩溃。 这让我产生了一些疑问,但我似乎在手册中找不到答案: 1)你是在初始化和启用外设之前还是之后设置 TRGMUX 链接? 2) TRGMUX 是否有任何模块时钟或类似设备?我知道在启用时钟之前访问模块可能会导致像我遇到的这种硬故障。我没有看到任何具体的东西,而且我的理解是 TRGMUX 寄存器是每个外设的一部分,所以启用外设的时钟也应该会启用任何所需的 TRGMUX 时钟? 谢谢你的帮助。 Re: TRGMUX Assistance - MCXE316 是的,添加这行时钟代码纠正了硬故障和 SDK 方法。我提出的直接编码方法也同样有效。 因此,一般来说,您需要启用 TRGMUX 时钟并设置 IMCR 寄存器,同时调用 SDK 方法进行 TRGMUX 连接。这样,LPCMP 就能正确触发 eMIOS 输入捕获。 感谢大家的支持。 Re: TRGMUX Assistance - MCXE316 好的,崩溃问题仍然存在,但进一步研究发现,我需要在设置 TRGMUX 之前设置 SIUL2 IMCR 寄存器。在参考手册附带的 IOMUX xls 文件中,我看到对于 eMIOS0_CH[7],需要将 SSS 位设置为 4 才能选择 TRGMUX_INT_OUT38,这是通过 SIUL_IMCR567 完成的(由于命名中的 512 偏移量,需要从 567 中减去 512)。以下是我用来实现此功能的代码行,后面是设置 TRGMUX 的代码行: SIUL2->IMCR[55] = SIUL2_IMCR_SSS(4); *(volatile uint32_t *)0x40080024UL = TRGMUX_TRGCFG_SEL3(kTRGMUX_SourceLpcmp0); 我仍然遇到 TRGMUX 硬故障。 Re: TRGMUX Assistance - MCXE316 嗨@brucebowling 很抱歉回复晚了。 我们注意到 TRGMUX 时钟默认情况下未启用。在时钟被禁用时尝试访问 TRGMUX 寄存器会导致 HardFault。你猜对了,钟表不见了。 请在调用 TRGMUX_SetTriggerSource 之前添加以下代码行? CLOCK_EnableClock(kCLOCK_Trgmux); 这项更改解决了我的问题。 作为参考,您可以在 SDK 中找到 TRGMUX 的使用示例: 板/frdmmcxe31b/demo_apps/mc_pmsm/pmsm_enc 请告诉我这是否解决了您的问题,或者您是否还有其他关于TRGMUX的问题。
查看全文