Hello all,

I have a the CYBT-213043-MESH board, and my question is this: Would it be possible to have a single application with both client and server capabilities run on these boards? If so, what would be the right way to go about achieving this?

Thanks,

Mariela

Stm32h743 is connected via FMC s29gl064s，and cubeide configed. As shown below:

RCC configured as below：

Read flash ID：

sts = HAL_NOR_Read_ID(&hnor1, &id);
printf("sts1 = %d\n", sts);

printf("nor_id = %04x %04x %04x %04x\n",
id.Manufacturer_Code,
id.Device_Code1,
id.Device_Code2,
id.Device_Code3);
HAL_Delay(1);

Return：nor_id = 0001 227e 2213 2201

Then ReturnToReadMode:
sts = HAL_NOR_ReturnToReadMode(&hnor1);
printf("stsreadmode2 = %d\n", sts);
HAL_Delay(1);

EraseChip：

sts = HAL_NOR_Erase_Block(&hnor1, 0, 0x60000000);
printf("sts_erase_block = %d\n", sts);

do {
sts = HAL_NOR_GetStatus(&hnor1, 0x60000000, 500);
printf("HAL_NOR_GetStatus1 = %d\n", sts);
} while(sts);

Return status look like correct.

Write operation：

uint16_t txbuf[1024] = {0}, rxbuf[1024] = {0};
#if 1
for (i = 0; i < 1024; i++) {
txbuf[i] = 0x5a;
}
#endif
sts = HAL_NOR_ProgramBuffer(&hnor1, 0, txbuf, 256);
printf("sts_write_buf = %d\n", sts);

do {
sts = HAL_NOR_GetStatus(&hnor1, 0x60000000, 500);
printf("HAL_NOR_GetStatus1 = %d\n", sts);
} while(sts);

Return status look like correct.

Read operation：

sts = HAL_NOR_ReadBuffer(&hnor1, 0, rxbuf, 256);
printf("sts_read_buf = %d\n", sts);
#if 1
do {
sts = HAL_NOR_GetStatus(&hnor1, 0x60000000, 500);
printf("HAL_NOR_GetStatus1 = %d\n", sts);
} while(sts);
#endif
for (i = 0; i < 256; i++) {
if (!(i % 8)) {
printf("\n");
}
printf("%04X ", rxbuf[i]);
}
printf("\n");

Return resaults as below：

 According to your tips, I added the HAL_NOR_ReturnToReadMode function.

But the result is still incorrect! Please help me look again. What's the problem。

Thanks.

Hello,

I'm working on a Dual Core Application in ModusToolbox using the CY8CPROTO-062-4343W proto board.  The project is setup so that the CM0P collects data and sends it to the CM4 core.  About 4 KB of data needs to be exchanged every second.

Originally, I thought about sharing a pointer since the physical memory is shared between the two cores.  However, looking at the linker scripts, I see that the logical memory between the cores doesn't overlap, and that makes sense since you can't have the heap allocators on each core overwriting the same physical address.

The IPC Pipes example project only sends 4 bytes of actual data.  I cannot find anything in the datasheets about how much data can be transferred over IPC.  Will this be able to support my required throughput?

Otherwise, is there a way to specify a small region of memory that is shared between the two cores?

Best regards,

Cory

Hey all,

I'm looking into interfacing a PSoC5LP to a bit of a strange I2C Master.  Rather than being designed to run on a bus, I have to interface using SDA/SCL and an INT pin in a "point to point" configuration.  The idea is easy enough, it gives a edge on the INT line, I catch it with the PSoC, and read the 9 data bytes that it sends, but there's a twist. 

The catch is this device does not send an address, just the raw data bytes.  How can I adjust the SI2C to account for this?  I see I can use either Software/Hardware address decoding.  Hardware is probably out of the question since there's just no address at all.

This leaves me with software decoding, in which case it seems like modifying the ISR in SI2C_INT.c to just drop bytes immediately into the buffer rather than doing a check on the address might work.  Maybe some custom code placed in the SI2C_SW_ADDR_COMPARE_interruptStart code block in the ISR?  I could maybe set the "expected address" to something that should never occur as the first byte received (would need to see if this is possible, it only has 1 bit of data, the rest are "Reserved", so maybe they'll read all 0?  That would make it easy.) so it will drop into the address compare where I can drop my custom code to place the data in the receive buffer rather than use it as an address?

An easier option after looking further may be just to use the SI2C_ISR_EntryCallback(); and have it perform essentially a modified version of the stock Slave I2C code.

I'd be interested if anyone out there had any better options, maybe even something that just works in hardware?

Thanks!

Hey all,

I'm trying to track down the cause of some PSoC5LP firmware running into the default interrupt with errno==ENOMEM.

The only way I've been able to reproduce it is to power cycle the PSoC quickly enough after powerup to catch it, and even then I've only been able to get it to occur maybe once every 50 or so cycles.  This makes using the debugger to track it down basically impossible from what I can tell.  It almost seems like it might be occurring when the PSoC is undervolted due to very quick loss and re-application of main power, so some "undefined behavior" might be occurring.  I know PIC MCUs I've worked with have a "Brownout Reset" function to automatically put the MCU into reset when VDD falls beneath a certain configurable voltage.  Does PSoC5LP have anything comparable?

I am running some BIT test on bootup in this firmware and *suspect* it occurs when I manage to power cycle/brownout the system while it is in progress of running these tests.  Specifically, I am running an SRAM March Test, a Stack March Test, and a Flash ECC Test on bootup.  The code for all these tests was taken from the examples in AN78175 (I made a thread about it months ago, actually: https://community.infineon.com/t5/PSoC-5-3-1/PSoC5LP-Using-SRAM-test-functions-from-AN78175/m-p/283692#M45177).

Right now when I manage to trigger the problem and enter the trap ISR for ENOMEM, I simply have it infinitely loop and blink an LED.  I wonder if it would be worth it to try and hunt the exact error cause down.  My other thought is that this occurs so infrequently and might be unavoidable enough, to just perform a software reset in the handler and call it a day?

I'd love a second or third opinion on maybe how I should track this down/handle it.

Thanks!

Hey,

We are using PSOC6 CY8C6347BZI-BLD53 for our product. I am trying to add additional timer counter blocks (tcpwm) which will bring our in project use to 27 timers. The chip has 32 blocks available. I get this error upon enabling the 23rd timer block

E2810: The solution search limit for pin and fixed function block placement has been exceeded.

Attaching a screenshot for the full error. When I only have 22 timers, the error goes away so I know it is the TCPWM block and no other components.

Is there a way to know if the other blocks are used elsewhere internally? We have BLE enabled alongwith several other blocks including wdt, spi, i2c, uart etc.

Thanks in advance,

Vandita

Hello Infineon Support,

I'm trying to setup ModusToolbox on a Raspberry Pi build server my team has for running builds with CI/CD.  I was able to install ModusToolbox on the Pi without any issues.

However, when I try to run make getlibs inside my project folder, I get the following output and error:

$ make getlibs
Tools Directory: /build/tools/ModusToolbox/tools_2.4/
make -C ../app_cm0p/ getlibs
make[1]: Entering directory '/var/lib/gitlab-runner/builds/<build-dir>/app_cm0p'
Tools Directory: /build/tools/ModusToolbox/tools_2.4/
==============================================================================
= Importing libraries =
==============================================================================
/build/tools/ModusToolbox/tools_2.4/proxy-helper/proxy-helper: 4: exec: /build/tools/ModusToolbox/tools_2.4/proxy-helper/bin/proxy-helper: Exec format error
make[1]: *** [/build/tools/ModusToolbox/tools_2.4//make/getlibs.mk:121: getlibs] Error 2
make[1]: Leaving directory '/var/lib/gitlab-runner/builds/<build-dir>/app_cm0p'
make: *** [Makefile:210: getlibs_cm0p] Error 2

I am using a CYW20706 based module (CYBT-343026).  I am using the modus toolbox example Audio_Sink for the CYW920706WCDEVAL platform.  The only changes I've made are to the wiced_platform.h to update the pinout for my PCB.

The problem is I get a periodic click when streaming from ios.  I do not see the issue with android.  The period of the click changes on each bluetooth connection, but stays the same while connected.  Somewhere between 1 and 2 sec.  Some connections do not click at all.

I highlighted in white the click while playing a 20Hz tone using a freq generator app.  The second pic is a zoomed in shot.

I then captured the i2s data using a logic analyzer and decoded it to see if it was in my audio circuit or in the data.  After decoding I do see the same shapes in the i2s output from the module.

I have verified both android and ios are negotiating the same 44.1kHz, max bitrate=53, joint stereo connections.  I'm not sure what to do from here. 

What settings can I make to fix this?

Thanks,

Mark

Hello,

I use Optiga Trust M Eval Kit to integrate Optiga Trust M in our product. We use the following example: 

https://github.com/Infineon/optiga-trust-m/blob/develop/examples/utilities/authenticate_chip/example_authenticate_chip.c

We observed that pal_crypt_verify_signature independently of Keys, Digest and Signature delivers return code 0xB380. This return code we cannot decrpyt according to the existing return codes. 
The return code is independent of the input data. We used input data from example_optiga_crypt_ecdsa_verify.c as well as python-generated random data. 

Please, explain why pal_crypt_verify_signature fails.

Best regards,