Welcome to the Infineon Developer Community

We have plan to use the BW2455-44P (sdio/dhd-android-1.363.125.19 <driver> ) with Sigma Star SDK(SAV837SDK_V15/Linux(kernel) version : 4.9.227).

The command(ping) is worked fine after connecting to AP.

Howerver, When I tried to do live view stream with VLC on the PC after the unit connected to AP(Router, The PC and unit are in the same nework), There was Cmd error ( [sdmmc_1] Err: #Cmd_53 (0xA900004A)=>(E: 0x0100)(S: 0x00000000)__(L:1059)(B:74/74)(I:0/1) dhd_bcmsdh_send_buf: sdio error -1, abort command and terminate frame).

- So, Could you help me how to fix the issue as soon as possible ?

- Please let me know which driver I should use to fix the problem.

Log contnets:

[0x39][DEBUG_BUS1]=
0x0500,
0x0500,
0x05E4,
0x051C,

------
>> [sdmmc_1] Err: #Cmd_53 (0xA900004A)=>(E: 0x0100)(S: 0x00000000)__(L:1059)(B:74/74)(I:0/1)
dhd_bcmsdh_send_buf: sdio error -1, abort command and terminate frame.
/customer/wifi #

Best Regards 

From Chad Cha

Hello,

I am using GPIO pins to generate some on off sequence on pin. But while generating it sometimes my sequence gets stretched as attached in file. here i am using Simple GPIO.

I am using for loop for the same.

for(i=0; i<=7; i++)
{
CyU3PGpioSimpleSetValue(45,CyTrue);
CyU3PBusyWait (1);
CyU3PGpioSimpleSetValue(45,CyFalse);
CyU3PBusyWait (1);
}

Let me know what i am missing.

Hello,

I'm writing code for communicating with a TLD7002 for a development tool, and would like to ask a few questions concerning the calculation of the CRC sums. As the driver library is not yet available to me, I'm implementing basic access to the HSLI in the programming language I'm using.

The datasheet of the TLD7002-16ES specifies two types of CRC algorithms, a 3-bit CRC, and an 8-bit CRC.

1. Regarding the 3-bit CRC, in the software design training video there appears a step where the crc value is reflected (mirrored) after processing the first 5 bits:

/* get reflected CRC3 value */
crc = TLD7002_MIRROR_MID_CRC3[crc];

I cannot find this step in the datasheet on page 67, though — an extra step reflecting the crc value after the first 5 bits and the tail 8 bits is not mentioned there; is the datasheet correct regarding the calculation of the 3-bit CRC?

2. The CRC-8 is defined as using the generator polynomial "0x8e = x^8 +x^4 +x^3 +x^2 +1" from CRC-8-AUTOSAR and SAE J1850.
But, from my understanding, 0x8E — binary: (1)-1000-1110 — actually is not the same as x⁸ + x⁴ + x³ + x² + 1;
0x8E is the reversed — LSB-first — form of 0x71  (1)-0111-0001, which corresponds to the polynomial x⁸ + x⁶ + x⁵ + x⁴ + 1, and is the reciprocal form, or Koopman representation, of the CRC-8-SAE polynomial 0x1D, but with similar properties:

(Source: Wikipedia)

So if the polynomial actually is 0x8E, then for calculating the CRC-8 of the safety byte the reversed, LSB first, algorithm would have to be used. Is this correct?
If yes, then this possibly also applies to the CRC-3, because two CRC sums used in the same HSLI frame are likely implemented in the same fashion. This could mean that the polynomial to be used when calculating the CRC-3 would be 0x6 ("reversed"), or 0x5 ("reversed reciprocal"), but not 0x3. Which one is actually used by the TLD7002-16ES?

The CRC-8 of SAEJ1850, by the way, also defines a final XOR step, where 0xFF is XOR'ed into the crc value. I suppose, since the datasheet of the TLD7002-16ES does not mention this, this final step of the original SAEJ1850 definition does not need to be performed in case of HSLI?

It could probably be helpful, if a table of example CRC results for various input values would be included in the datasheet, similarly as it is done in the Autosar document Specification of CRC Routines; this way users could perform a test for plausibility of their crc implementations, before sending actual requests to the TLD7002. 

Regards,
Michael

Environment and SDK information:
WICED version: 6.4
Wi-Fi Module: Murata Type1GC

Wi-Fi connection(to wireless LAN AP) is lost immediately after 11 hours past with WPA3-SAE.
We think it was caused due to Wi-Fi module is down. It's not disconnected by wireless AP.
And we have already tried other wireless LAN AP from several vendors, and we confirmed that the same issue was reproduced in every case.
However, if we choose WPA2-PSK, the issue doesn't happen. Wi-Fi connection is still alive after 11 hours past.

Do you have any solutions to this issue?

Hi team,

I added different resolutions to my custom camera board with the help of this  link .

I have taken care of probe control settings and descriptor settings while adding different resolutions.

Currently I am facing some issues and I would like to have a help from you.

1. I can able to stream 13MP resolution over USB 2.0 but for some lower resolutions like VGA I'm getting black screen in AMCap. But I am getting image in windows camera app, why is this  happen ? Did I miss anything?

2. 13MP resolution streaming is perfectly being done and I have added still capture capability to it. When I try to capture image, the streaming is getting interrupted and on to UART log side I'm getting DMA_RESET(continuously starting and stopping the App). May I know why this happening?

Your help is most appreciated.

Thank you,

 Abdul.

I have been trying to write a program that involves Digital Write and USBUART. The program doesn't seem to work for some reason. 

This is a sample code. When I comment out the digital write statements, the USBUART works. And when I comment out the USBUART, the Digitalwrite works. Any idea why?

Any help is greatly appreciated.

#include "project.h"
#include <stdio.h>
int main(void)
{
    CyGlobalIntEnable; /* Enable global interrupts. */

    ADC_SAR_Start();
    AMux_Start();
    USBUART_Start(0,USBUART_5V_OPERATION);
    
    while(USBUART_GetConfiguration()==0){}
    
    ADC_SAR_StartConvert();
    
    /* Place your initialization/startup code here (e.g. MyInst_Start()) */

    for(;;)
    {
        /* Place your application code here. */
        
        LED_Write(1);
        CyDelay(1000);
        LED_Write(0);
        CyDelay(1000);
        
        AMux_Select(0);
        int pot1 = ADC_SAR_GetResult16(); 
        AMux_Select(1);
        int pot2 = ADC_SAR_GetResult16();
        
        char print[100];
        sprintf(print, "pot1 : %d, pot2 : %d\r\n", pot1, pot2);
        USBUART_PutString(print);
        CyDelay(100);
        
    }
}

Is the calibrated / compenstated pressure output supposed to correct for ambient temperature changing?

the scaled raw temp value is featured in the equation for the comp pressure but if i heat the sensor without changing the pressure, the comp pressure reading drops (not expected) and the calibrated (degrees C ) temperature climbs (as expected)

i have 2 different sensors that behave the same, i can see the calibration coeffs are different but in the same ranges for each parameter so I am pretty sure I am doing all the right stuff with the numbers as the calibrated outputs are 'correct' in as much as they output believable numbers but with heat alone as a modulation to the sensor, the pressure is moving

am i missing something here?

i am hoping to use the 2 in a differential mode which seems ok so far as long as the temperatue doesn't change

thanks

Andy