PSoC™ 4 Forum Discussions

Hi!

Each time I connect my pioneer kit to an external psoc-4 chip, it lands up in the mass storage mode.

I had burnt a bootloader program in the external chip, now that chip is simply not getting re-programmed. It sends the poineer kit to mass storage mode. What to do?

Hi,

   We are using PSoC4 in a combo BLE and capsense application. To try and reduce noise we are attempting to to perform capsense activity between BLE intervals. As there is a whole mess of capsense we are doing, ie takes a lot of time, this is non trivial.

  The summary of the plan is like this. Usually you have something like:

  while(1)
    {
        /* CyBle_ProcessEvents() allows BLE stack to process pending events */
        CyBle_ProcessEvents();

        //do your stuff

     }

while doing "our stuff", we are interested to know how much time is remaining before BLE will want to do something. The application notes on how to enter bless deep sleep offers a solution.

        uint16_t start_instant = CY_GET_REG32(CYREG_BLE_BLELL_TIM_COUNTER_L);

        uint16_t adv_instant = CY_GET_REG32(CYREG_BLE_BLELL_ADV_NEXT_INSTANT);
        uint16_t init_instant = CY_GET_REG32(CYREG_BLE_BLELL_INIT_NEXT_INSTANT);
        uint16_t scan_instant = CY_GET_REG32(CYREG_BLE_BLELL_SCAN_NEXT_INSTANT);
        uint16_t ce_instant = CY_GET_REG32(CYREG_BLE_BLELL_NEXT_CE_INSTANT);

 We then choose the closest event. and continually check CYREG_BLE_BLELL_TIM_COUNTER_L to see if we are running out of time. So far so good i hope. However the trouble happens right in the beginning. The docs say that we must check if the LL is idle before reading TIM_COUNTER_L, ie CY_GET_REG32(CYREG_BLE_BLELL_CLOCK_CONFIG) >> 7) & 1.

Under some circumstances, this operation *appears* to throw a hardfault. Now I can picture this happening if some peripheral clock gets turned off and this is an illegal read, but the read works in the debugger so I can't rule out anything. Could be memory corruption, stack troubles, some fault on ISR return.

We are looking for clarification as to whether or not there is actually some circumstance that would cause said read to fault, and if so, what is the workaround.

Regards,

Jon Pry

I'm Using a CYBLE-022001 module and trying to keep the current consumption down to a minimum.

I noticed higher than normal current levels when connecting to the module using an iPhone5. The behavior is not apparent when using an iPad, an Android phone or the CySmart App on a PC.

When I connect with the iPhone the BLESS will transition in and out of DeepSleep for the first few events and then refuses to go back into DeepSleep for up to a minute and then at random decides to drop back into DeepSleep as it should, just waking at each connection event.

For an iPad, Android and CySmart on PC the following are a typical event logs:

** CySmart 1.2 **

GATT_CONNECT_IND
GAP_DEVICE_CONNECTED
L2CAP_CONN_PARAM_UPDATE_RSP (ACCEPT)
GATTS_XCNHG_MTU_REQ
GAP_CONNECTION_UPDATE_COMPLETE
....
GATTS_READ_CHAR_VAL_ACCESS_REQ

** iPad **

GATT_CONNECT_IND
GAP_DEVICE_CONNECTED
GATTS_XCNHG_MTU_REQ
L2CAP_CONN_PARAM_UPDATE_RSP (ACCEPT)
HCI_STATUS (Error 04 - PAGE TIMEOUT)
GAP_CONNECTION_UPDATE_COMPLETE
....
GATTS_READ_CHAR_VAL_ACCESS_REQ
 

The iPhone typically produces an event log as follows:

GATT_CONNECT_IND
GAP_DEVICE_CONNECTED
GATTS_XCNHG_MTU_REQ
L2CAP_CONN_PARAM_UPDATE_RSP (ACCEPT)
HCI_STATUS (Error 04 - PAGE TIMEOUT)
....
GATTS_READ_CHAR_VAL_ACCESS_REQ
 

Notably the iPhone connection doesn't include the 'Connection Update complete' event and if I suppress the connection interval update, the problem doesn't arise with the iPhone.

A common DeepSleep lockout occurs shortly after the L2CAP_CONN_PARAM_UPDATE_RSP (ACCEPT) event occurs as with all of the clients but doesn't return to normal in the case of the iPhone, presumably due to the lack of GAP_CONNECTION_UPDATE_COMPLETE event?

Also with iOS it seems that the Page Timeout error occurs in both cases. I am not sure what this is referring to unless its the lack of connection update response in the case of the iPhone but doesn't seem to be a problem for the iPad connection??

Just to add to the confusion I can sometimes get the iPhone to connect without the DeepSleep problem when initially powering up the ez-ble module!

The connection parameters I am trying to use are shown below but have tried many other combinations, keeping within the apple guidelines:

CYBLE_GAP_CONN_UPDATE_PARAM_T connParamsSlow =
{
    152,                /* Minimum connection interval - 152 x 1.25 = 190 ms */
    168,                /* Maximum connection interval - 168 x 1.25 = 210 ms */
    0,                  /* Slave latency - 0 */
    200                 /* Supervision timeout - 200 x 10 = 2000 ms */
};

I was originally using the BLE component v2.20 but updated it to V2.30 without any improvement.

Can anyone shed light onto what I am seeing here and offer a possible workaround to get the module to go back into DeepSleep correctly?

I've built a frequency counter on PSOC 4 (CY8CKIT-49-42XX), starting from one example found on Internet.
I'm using UDB block just to learn to use them. (May be simplest?)
The project seem to work , but the frequency shown on LCD isn't precise. The readouts on display oscillate  around 6 -7 % lower, from the correct value (compared with external frequency meter and oscilloscope).
I'm not sure why, may be the clock reference? This clock is precise within 1% (as declared on composer), so I doen't aspect  a so large oscillation.
Where is my mistake? Can the clock reference be the cause my error, or is something on my implementation?
Better if I use an external clock?

Attached the project.

Thanks for help,
Fabrizio

Hi, Is there another way to measure an RTD sensor without using IDAC?

Tks.