PSoC™ 6

Hi,

We are trying to  solve a problem with the BLE system randomly failing while the device is connected to a peripheral and sending data. Upon failure Cy_BLE_GATT_GetBusyStatus()  returns CY_BLE_STACK_STATE_BUSY indefinitely. We have tried to reset the BLE system but it does not advertise or scan after the reset.

Solutions tested:  

• Soft-resetting the BLE stack 
• Called Cy_BLE_StackSoftReset(), the function returns CY_BLE_SUCCESS 
• Checked the state of the stack by calling Cy_BLE_GetState(), the result was CY_BLE_STATE_ON 
• The BLE did not behave as normal as it was not advertising or connecting to any other devices 

• Hard resetting BLE system 
• Called Cy_BLE_Stop() on CM4 with results being CY_BLE_SUCCESS 
• Called Cy_BLE_Start() on CM0+ with results being CY_BLE_SUCCESS 
• Called Cy_BLE_Start() on CM4  with results being CY_BLE_SUCCESS 
• Checked the state of the stack by calling Cy_BLE_GetState(), the result was CY_BLE_STATE_INITIALIZING 
• The BLE did not behave as normal as it was not advertising or connecting to any other devices 

Note: Resetting BLE was tested independently of the busy stack issue by manually triggering the soft and hard resets. 

Any clues as to why the stack is busy in the first place or why the resetting process is not working would be appreciated.

I am using CY8CPROTO-063-BLE PSoC 6 BLE Prototyping Kit, and I want to send heart rate sensor data to the CySmart mobile app over BLE. I am new to CyPSoC devices and having some trouble making the connection.

Are there any code examples I can follow to do this with some explanation of the code?

I found several example codes on the internet on how to send data into the PSoC6 via BLE. But so far, no luck finding a good code to take data from PSoC6 via BLE.

Any help or advice is highly appreciated. 

Hi 

I made custom BSP for CY8C6244AZI-S4D93.

I was trying to add DAC configuration using MTB but I think there are some problem with connection verification.

According to below diagram, direct output of DAC is able to connect with pin 6 of CTB port.

In this IC, CTB port is port 9 and pin 6 is not available.

so the other way to make output path of DAC is using buffer.

as you can see in following picture. When I set DAC output as buffered output, there is only one option that I could choose to use as DAC output path is v plus of opamp0.

but the indicator always shows me yellow light even I tried every other combination of connections.

of course I tried it after disabled all other peripherals even the debugging port. 

could you check this point?

I would like to confirm my observation when calling the Cy_Crypto_Core_ECC_SignHash() and Cy_Crypto_Core_ECC_MakeKeyPair() functions.  The Cy_Crypto_Core_ECC_MakeKeyPair() returns the public key (X & Y) in little endian format, same for the signature (R & S) returned by the Cy_Crypto_Core_ECC_SignHash() function.  I verified this by using Mbedtls to generate the public key from a private key created by Cy_Crypto_Core_ECC_MakeKeyPair().

Hi.

I'm trying to use the HAL System Power Management library to put the CM4 to sleep. So far, I've had no luck, and as I have found too many times, there is very little documentation available, and no examples. What documentation exists (e.g. Architecture TRM) is unclear, even suggesting that only masked interrupts can wake up a sleeping CPU.

Here's the environment:

• PSoC 63 with BLE in a custom board.
  • MTB 2.3.0 
  • BSP 2.3.0
  • PDL 2.3.0
  • HAL 2.1.0
• CM4 and CM0+ running FreeRTOS
• Several peripherals in use (BLE, I2C, UART, SPI, RTC, TWPCM, etc.)

1. I registered four callbacks using cyhal_syspm_register_callback(). 
2. I call cyhal_syspm_sleep().
3. The four callbacks are called with state set to CYHAL_SYSPM_CB_CPU_SLEEP and mode set to CYHAL_SYSPM_CHECK_READY. All callbacks return true.
4. The four callbacks are called again with state set to CYHAL_SYSPM_CB_CPU_SLEEP, but this time mode set to CYHAL_SYSPM_BEFORE_TRANSITION.
5. The four callbacks are immediately called a third time with state set to CYHAL_SYSPM_CB_CPU_SLEEP, but this time mode set to CYHAL_SYSPM_AFTER_TRANSITION.

The first problem is that the CPU either doesn't sleep, or wakes up immediately. I disable the RTOS SysTick interrupt in one of the callbacks. I also disable several other peripheral interrupts, and turn off the BLE stack, none of which has made a difference. It's likely that some interrupt is firing, but I can't think of a good way to determine which is the culprit.

The second problem is that the stated behavior, namely that the callbacks are called on wakeup (CYHAL_SYSPM_AFTER_TRANSITION) in the reverse of the order in which they are called on sleep (CYHAL_SYSPM_CB_CPU_SLEEP) does not match the observed behavior.
Callbacks are always called in the same order, even when one of the callbacks returns false in response to CYHAL_SYSPM_CHECK_READY.

Has anyone successfully used cyhal_syspm_sleep() to put one of the CPUs to sleep?

Thanks,

-Nick

I'm using a a CY8CKIT-062-BLE with the EINK display.

I have two projects using this kit.

One works to update the display the other does not.

On the one that doesn't work (link) it complains about a code line using:

LCD_GetDisplayBuffer().

The linker complains and aborts:

.\CortexM4\ARM_GCC_541\Debug\main_cm4.o: In function `UpdateDisplay':
C:\Users\lpoma\Desktop\SineGen_Audio\SineGen_Audio_EINK_062-BLE.cydsn/main_cm4.c:174: undefined reference to `LCD_GetDisplayBuffer'
collect2.exe: error: ld returned 1 exit status
The command 'arm-none-eabi-gcc.exe' failed with exit code '1'.

I compared the build specs of the two projects and the issue is not immediately apparent.

Apparently I'm missing a em-Win library reference some where.

I can use some expert help here.

Thanks in advance.

Hello,

I have questions about Flash and Emulated EEPROM.

1. The flash endurance is described in the datasheet as 100k cycles.
Does each row of flash individually have 100k cycle endurance?

2. I'm using the Emulate_EEPROM example in modus toolbox. (CY8CKIT-062-WIFI-BT)
Please let me know how it works internally when using Em_EEPROM.

I want to know about the case of repeatedly writing a few bytes of data to the same address.
For example, when only a few bytes are to be written, will the entire line (512 bytes) including this address be erased and re-written?
Does the Em_EEPROM algorithm read the entire existing row of data into RAM before it is deleted, then modify only a few bytes and write it to flash?

Thanks and Regards,
YS