PSoC™ 6 Forum Discussions
Hi All,
I'm trying to get SPI working on my custom target board, which contains a CY8C6116 PSoC.
Using the Device Configurator in MTB 3.0.0, I've selected SBC-5 for SPI 1.0. P11_0 thru P11_3 are configured as; SPI_MOSI, SPI_MISO, SPI_CLK, and SPI_CS0 respectively. There are no warnings about individual pins in the configurator. The symbols are resolved in the code, even though the compiler raises warngings that they're not.
I've added the following init:
cy_rslt_t rslt;
cyhal_spi_t sSPI;
/* Configuring the SPI master: Specify the SPI interface pins, frame size, SPI Motorola mode and slave mode */
rslt = cyhal_spi_init(&sSPI, CYBSP_SPI_MOSI, CYBSP_SPI_MISO, CYBSP_SPI_CLK, CYBSP_SPI_CS, NULL, 8, CYHAL_SPI_MODE_00_MSB, true);
Stepping through the code:
Upon calling cyhal_spi_init(), the symbols values are passed as expected.
Things proceed as expected until about 60-70 lines later (still in the cyhal_spi_init function) when the _CYHAL_SCB_FIND_MAP macro is run. Line 398 of cyhal_spi.c is as follows:
mosi_map = _CYHAL_SCB_FIND_MAP(mosi, cyhal_pin_map_scb_spi_m_mosi);
The macro leaves mosi_map without the correct info. Here's the macro definition from line 155 of cyhal_scb_common.h:
#define _CYHAL_SCB_FIND_MAP(pin, pin_map) \
_cyhal_scb_find_map(pin, pin_map, sizeof(pin_map)/sizeof(cyhal_resource_pin_mapping_t), NULL)
When _cyhal_scb_find_map() is called in the expanded macro, it never finds a match between the pin and the block type. Once it finds the pin (e.g., P11-0), the block type is always CYHAL_RSC_ADC. (It's looking for a CYHAL_RSC_SPI.)
Can anyone tell me what's causing this? I'm new to the PSoC6, MTB, and the Device Configurator (not to mention all the included abstraction). I wouldn't be surprised if I'm making a rookie mistake.
Thanks,
robin
Xin chào!
Tôi có câu hỏi về các dòng của PSoC, Dòng lệnh ở trên #nếu được xác định(CY_DEVICE_PSOC6A512K)
/* nếu mục tiêu là CY8CPROTO-062S3-4343W hoặc CY8CPROTO-064B0S3*/ và Dòng lệnh #nếu được xác định(CY_DEVICE_PSOC6A256K) /* nếu mục tiêu là CY8CKIT-062S4 */. Vậy làm cách nào để xác định tôi đang sử dụng PSoC nào?
Cám ơn!
Show Less
Hi,
I think I don't have the correct driver for my Eval Board. How to fix it? It should be 'KitProg3' or similar. Previously it worked, maybe I have installed an another MCU development environment.
Show Less
While running code, i.e. executing from the built-in flash, is it possible to do non blocking writes to the Auxiliary flash section?
same question goes for erasing it.
Show LessHi All,
I've been working on a project for a couple of weeks, uploading code to my target system from MTB, using a MiniProg4. Programming the part and debugging code from MTB, connected to the target through a MiniProg4.
All has gone smoothly until yesterday. I had been alternately making code changes and building/debugging successfully, when all of a sudden, inexplicably I got the following error message:
** Program operation completed successfully **
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
Info : SWD DPIDR 0x6ba02477
shutdown command invoked
Info : psoc6.dap: powering down debug domain...
Warn :
*******************************************************************************************
* KitProg firmware is out of date, please update to the latest version (2.40.1241)
* using fw-loader tool which can be found in the following folder
* C:/Users/rvice/ModusToolbox/tools_3.0/fw-loader
*******************************************************************************************
After getting this message, I cannot debug.
I see a lot of references on-line to updating the PSoC6 WiFi BT Pioneer kit from KitProg2 to KitProg3. But I'm not using the kit. This is a CY8C6116 loaded on my proprietary prototype PCB.
I can successfully connect to the target using the Cypress Programmer 4.0.1 software. Through Cypress Programmer I can; read, erase, program, and verify without issue. Using the same hex file generated by MTB.
Can anyone shed some light on what's going on?
Thanks in advance,
robin
Hello Infineon Community,
I have been working with PSoC 6-based CY8C6244LQQ-S4D92 microcontroller. The issue with this MCU is happening when I am trying to read the state of the P12.6 and P12.7 pins, every time when I read the state of these 2 pins, it's always low if it is connected to the 3.3V supply also. Otherwise, other input pins are working fine, just these two pins are showing some issues. I tried to change the mode of these two pins also but didn't succeed.
Please help me with this issue.
Thanks & Regards,
Vivek Karna
a few years back I did this, but I've lost track of where I got the utility. I need to put an image on the display. From my recollection I had to take the image (jpg I think) and run it through a utility that the e-ink manufacturer sent me. I got that information from you folks. Could you provide me the contact information or website for the e-ink manufacturer so I can get this utility again? Many thanks.
Steve
Show Less
Hi ,
I am working on the PSOC62 free-running WDT , I followed the example in the following link to use the PDL as i am working on the CM0.
The interrupt part of the sample works fine , but we when I invoke the WDT_RESET_DEMO the unit does not trigger a reset as per the documentation . In the WDT_RESET_DEMO mode the code does not use the interrupt ISR to do anything , as i understand it in the background after it has had 2 un handled interrupts on the 3rd it should do a reset . This does not happen . I have changed the Cy_WDT_SetMatch(0); value between 0 and 32000 to give me 1 second triggers but it also does not change it .
I also would like to reset the WDT counter via my system tick , according to the documentation this cannot be done while the WDT is enabled . So it means every 100ms or so i need to disable the WDT , clear the counter , and re enable it . if the system should go into a freez state in this routine the WDT wont reset either as it is now disabled which is a problem.
Using the Cy_WDT_ClearWatchdog(void) to reset the watchdog seems a bit redundant as it only calls the Cy_WDT_ClearInterrupt(void) function which feel a wasted process time . The question here though is , what does it mean by calling this clear interupt flag that the watchdog resets according to the documentation, does it also reset the counter value?
" The WDT_MATCH bit of the SRSS_INTR register is set
whenever a WDT match interrupt occurs. This interrupt must
be cleared by writing a ‘1’ to the same bit. Clearing the
interrupt resets the watchdog. "
I tried adding this to the systick code to clear the watchdog every 100ms , it does nothing and in the interrupt mode the watchdog ISR still kicks in.
What is the correct way to clear and reset in software the watchdog to make sure the interrupt or watchdog in reset mode does not fire ?
Attached is the Timer codes C and H files for review , this runs on the PSOC 6 Cy8c6247 cm0 is set to 100Mhz
Any assistance is welcome .
Regards
C
Show Less
Hello -
I’ve been using the CY8C6247BZI-D54 in a project for a while. My code loads/runs/I can debug it (using PSoC Creator) just fine.
We just got new boards in with a new batch of chips. I can load code over JTAG, but can’t debug (it gives some sort of a timeout error).
I ran across this article (https://community.infineon.com/t5/Knowledge-Base-Articles/Configuring-the-PSoC-6-MCU-Startup-Time-from-Reset-KBA232330/ta-p/284800), and thought maybe I could adjust the “listen window” for JTAG connections using a TOC2 header.
NOTE: my current project does NOT have a TOC2 header.
I decided to dump the memory at SFLASH address 0x16007c00, and was surprised to find a TOC2 header there already. I went back to an old board/device (several old boards), and see that the region is all zeros (as expected).
So, it’s only the new device that seems to have a preprogrammed TOC2 header. I checked a second board from the new batch, and it has the same. It also cannot be debugged over JTAG.
I noticed that the part number on the new chips is CY8C6247BZI-D54ES3 (“ES3” suffix). Is that “Engineering Sample” (datasheet part number guide makes me think that could be it)
I don’t know the source of these chips - given supply chain issues, I suppose it could have come from anywhere.
I tried to ZERO-out the TOC2 section on the new chip, and ended up with a “brick” (no longer executed my code). The same happened when I corrupted the CRC (in hopes of it using defaults).
Luckily, I was still able to reprogram with JTAG, so after restoring the TOC2 section in SFLASH, the board was recovered (but I still can’t JTAG debug).
NOTE that the TOC2 header that is pre-programmed in these devices has a valid “magic” and CRC, but the “TOC2_FLAGS” value is “0x00000000” (which doesn’t match what the “defaults” are documented to be for this chip, and could explain the inability to debug over JTAG.
Maybe I can write a ‘good’ value there, and it will enable JTAG debug? I’m worried that I may end up making a brick that can no longer be programmed over JTAG.
Thoughts?