PSoC™ 6 Forum Discussions

I use CY8CKIT-064B0S2-4343W to run some examples

in this project "Secure_Blinky_LED_FreeRTOS"

When I execute following command (Secure Boot), I get an error. 

Step A & B worked as expected

but,running command "cysecuretools -t cyb06xxa entrance-exam"

or

"cysecuretools -t cyb06xxa -p policy/policy_single_CM0_CM4_swap.json provision-device"

will shows the following error

VTARG is 2.5V and KitProg3 is in DAPLink Mode

我使用CY8CKIT-064B0S2-4343W的範例cysecuretools -t cyb06xxa entrance-exam

步驟A和B都正常，但是C跟D都會跳出 下列的錯誤訊息

P : WARN : Skipping CoreSight discovery for AHB-AP#2 because it is disabled
C : ERROR : Memory transfer fault @ 0xe000ed00-0xe000ed03. Check the log for details Error: Failed processing!

想請問一下要如何才能解決此問題

Hello, everyone!

Although this is more of a PDL question than a PSoC question, I'm moving this question here, since I'm working with the PSoC 6. 

Using the PDL, can a single SPI transaction be split into two calls to Cy_SCB_SPI_Transfer(), such that the slave device sees one continuous transaction?

Take for example a command 0x01 that returns 16 x 2-byte words of data.  Using a single transaction works:

uint8_t buff[33], result[33];
buff[0] = 0x01;  // Command
buff[1] ... buff[32] = 0; // Dummy bytes to shift in the data.

Cy_SCB_SPI_Transfer(SCB, buff, result, 33, context);

The data is all received, but the 32 byte result is byte-aligned starting at result[1] because of the full-duplex transfer.  I ideally, I want the result at result[0] and need to discard the first full-duplex transfer. 

To align the result, I think I need to split this into two calls. Naively, I tried:

uint8_t cmd = 0x01;  // Command
uint16_t result[16];

Cy_SCB_SPI_Transfer(SCB, &cmd, NULL, 1, context);
while (Cy_SCB_SPI_IsBusBusy(SCB))
    ;
Cy_SCB_SPI_Transfer(SCB, NULL, &result, 32, context);

But I suspect that the PDL treats the second call as it's own transaction and I don't get the data back from the chip. 

Is there a way to discard the full-duplex result of the command byte so that only the bytes returned from the chip end up in the result array?  If so, what calls do I need to make and in what order?

Thanks,
Peter

1  psoc62+connectivity 是目前流行的 wifi BLE方案

如上图所示,是可以的,并且是官方推荐的 

2  如果是PSOC63芯片,则默认的 connectivity 是无连接的 ,现在客户有个想法 是 PSOC63芯片+CYW43012,二者通过SDIO 接口来连接,请问硬件和软件是否可行,谢谢

3  

CYW43012的封装在 官方网站我并没有搜索到 ,您知道怎么搜索到吗? 我主要是想知道这几个封装区别

4   请问 CYW43012在PCB 设计的时候有设计指南吗 ?

My project is set up with local git. It is self contained so it does not use the share folder. It works... actually it builds without errors. I still get some weird stuff when I program my custom board but that's for another post. I renamed the main project in Eclipse (I made a backup copy before I started) by left clicking on its name and picked "rename". It took a bit of time (refactor) and renamed the project/main folder. I build the new named project and all was ok. No errors. But when I went to program the board I got an error when I click on the (launches) program (Kitprog3 ...). Something about can not find the dynamic variable cy...path or something like that. Sorry I'm using a different computer to type this post I don't remember the exact variable name.

I want to have a copy of the project with a new name. I don't care if I have to rename and then manually copy the project or just save the current project to a new name. How do I do that without getting the error? or how do I fix the error?

Thanks.

Hi,

I'm trying to connect PSoC6 to the external SPI master through SPI.

Is it possible to change the default MOSI/MISO pin mapping of PSoC6's SPI as like the below?

In CYB06445LQI-S3D42, when SCB4 is set as SPI Slave

MOSI : P7_0 (default) -> P7_1

MISO : P7_1 (default) -> P7_0

When I've tried it by just swapping MOSI and MISO pin mapping at the function "cyhal_spi_init", it has been failed.

Thanks,

Hello,

I am trying to run a security app using custom BSP for CY8C6247FTI-D52.

Using ModusToolbox 2.4.1 I:

• downloaded the example https://github.com/Infineon/mtb-example-psoc6-security for CY8CPROTO-062-4343
• changed the target to PSOC6-GENERIC
• added my custom BSP (make bsp TARGET_GEN=myBSP DEVICE_GEN=CY8C6247FTI-D52)
• changed the target in Makefile for all applications (bootloader, cm0, cm4)
• created a configuration in Device Configurator for all applications
• modified shared config linker scripts
  
• I have compiled the bootloader, it detects the absence of the application or its correct digital signature after uploading to the FLASH memory with the programmer. There are no problems with it. Below is the output from the compilation:
  
• The CM0 application is also fine, I can debug it. Here is the output:
  
• The CM4 application compiles without problems, but I can't debug it and I can't see any output from it, eg changing the GPIO state.
  

The CM4 application doesn't even enter the assembly code in startup_psoc6_01_cm4.S . I checked this by defining the Cy_OnResetUser function, which should be called first from the startup level before initializing the BSS, clocks, calling main(), etc.

I checked it for bootloader and CM0 application where I successfully jump into this function. But for CM4 I don't see such a result. This makes me believe that for some reason CM4 is starting from the wrong place in memory or not starting at all.

There is a Cy_SysEnableCM4 call in the CM0 application that should start CM4 from the appropriate FLASH location.

The function argument value 0x10030000 is valid, as you can see in the screenshot from the debug session.

The problem occurs when a value 0x5fa0003 is assigned to the CM4_PWR_CTL register, which results in a HardFault of the CM4 core, and there is nothing to fail in this application because in Cy_OnResetUser there is an infinite loop for(;;){}

According to the documentation https://www.infineon.com/dgdl/Infineon-PSoC_6_MCU_PSoC_62_Register_Technical_Reference_Manual-AdditionalTechnicalInformation-v07_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0f9480c901dd 4.1.12 value stands for enabling the CM4 and setting VECTKEYSTAT.

Further hours of debugging led me to a bootloader with the following code:

#if is omitted on CY8CPROTO-062-4343W but on my CY8C6247FTI-D52 Cy_SysDisableCM4 is called and I believe this is the real source of my problems. I know that for my CY8C6xx7 the CM4 starts after a reset, hence the manual shutdown for the purpose of copying FLASH in the bootloader. There must be some problem between disabling and enabling the CM4 core.

Could you point out where I should look for a solution to the problem? Maybe it's something related to LDO configuration, clocks, CPU sleep, etc.

In the PDL documentation https://infineon.github.io/psoc6pdl/pdl_api_reference_manual/html/group__group__syspm.html I see that there are a lot of mentions on this topic for CY8C6xx7. I am using PDL 2.4.1 https://github.com/cypresssemiconductorco/mtb-pdl-cat1#release-v2.4.1 

Best regards,
PZbb

Hello, world!

I am seeing inconsistent behavior between two identical statements while debugging an application using PSoC Creator 4.4 on the M4 (Pioneer kit CYC6347BZI-BLD53).  In a nutshell, when I set a breakpoint and inspect a variable in the debugger after a mathematical operation, I do not see the correct result.  

int adxl_read_reg_multiple(adxl_spi_handle *spi, unsigned char reg,
                                  unsigned short count, unsigned char *val)
{
    reg = (reg << 1) | ADXL_SPI_RNW;  // ADXL_SPI_RNW = 1

    unsigned char r1 = 0;   
    r1 = (r1 << 1) | ADXL_SPI_RNW;
    
    return spi_write_then_read(spi, &reg, 1, val, count);
}

This function is called with the reg argument = 0.  Setting a breakpoint at the first statement, the debugger shows reg = 0 (as expected). Step over the statement, and the debugger still shows reg = 0  -- when the new value clearly should be 1!  Step over the same statement for r1, and the debugger shows r1 = 1 -- but reg = 0 for the same operation.  They should both be 1.

Somewhere in the chain between the compiler, M4, and debugger something is not right. I looked in startup_psoc6_01_cm4.S and the default stack size is 4K., so I don't think I'm running out of stack for a shallow call chain.

This call sequence is taken from the ADXL372 code from Analog Devices. The wrong register value ends up being sent to the chip as a result of this problem (a 0 instead of a 1). If I can figure out what's happening in this test case, hopefully the driver will work. I've removed the actual peripheral code, which isn't necessary to reproduce the issue. 

If anyone has any idea what's going on, I'd like to hear it. 

Respectfully,
Peter