So even when trying clean and build, wrkspc would still not compile.
I removed main.c, handlers.c and ezapi.c..... then added them back in... and now it compiles.
Is this issue fixed in PSoC Creator 4.x?
Can you describe the steps you went through from the beginning? The host demo PSoC Creator project provided in the host library was built for the standard Pioneer kit, not the BLE Pioneer kit (though it could be adapted for that with little effort). I haven't encountered the kind of problem that you describe here, but I can't rule out something possibly path-related with some of the project definition files.
It should just work with a standard error-free installation of PSoC Creator, that much I can say for sure.
Thanks Jeff. I forget the exact sequence of events. No big deal. I'll be updating to the latest PSoC Creator and will advise if it ever reoccurs.
I have two CY8CKIT-042-BLE kits. Can the EZSerial_Host_Demo.cywrk be run on one of the kits with the provided "red" PSoC BLE module and just not use the BT capability. Then this kit is wire jumpered to another kit w/ a BLE module running the CYSPP image.Then, a BLE client is connected (ie.. CySmart on iOS).
I'm trying to determine how this demo is most effectively implemented.,,, and what additional info can be extracted from the demo above and beyond using TeraTerm to send/recv API commands to a BLE Pioneer kit w/ a CYSPP module.
Yes, it should certainly be possible to run one of the red BLE modules as the host using UART only without BLE capability. You would need to make at least the following changes:
- Modify the target device to the CY8C4247LQI-BL483
- Make sure the SCB UART pin connections are still on P0.4/P0.5 for RX/TX
- Change the UDEBUG TX pin to P1.5 for simple host monitoring through the built-in PSoC 5LP USB-UART bridge on the base board
Once you've done this, connect jumper wires between host kit P0.4 and EZ-Serial kit P1.5, and host kit P0.5 and EZ-Serial kit P1.4 (basically RX-to-TX and TX-to-RX as you would any other UART connection). You should be able to compile and flash the host demo onto the red eval module and monitor its debug output with the main board's virtual serial port.
It seems that your host example is targeting a perif server. I'm looking to support central client debug messages and added the case:
case EZS_IDX_EVT_GATTC_DISCOVER_RESULT: UDEBUG_PutString("RX: evt_gattc_discover_result: conn_handle="); printHex8(packet->payload.evt_gattc_discover_result.conn_handle); UDEBUG_PutString(", attr_handle="); printHex16(packet->payload.evt_gattc_discover_result.attr_handle); UDEBUG_PutString(", attr_handle_rel="); printHex16(packet->payload.evt_gattc_discover_result.attr_handle_rel); UDEBUG_PutString(", type="); printHex16(packet->payload.evt_gattc_discover_result.type); UDEBUG_PutString(", properties="); printHex8(packet->payload.evt_gattc_discover_result.properties); break;
However, I am seeing this API parser hang probably due to a bunch of DR events that occur when the central connects to a perif as typ shown below (text format):
@E,0029,DR,C=04,H=0001,R=0007,T=2800,P=00,U=0018 @E,0029,DR,C=04,H=0008,R=000B,T=2800,P=00,U=0118 @E,0045,DR,C=04,H=000C,R=0015,T=2800,P=00,U=00A10C2000089A9EE21115A133333365 @E,0010,RPC,C=04,R=060A @E,0029,DR,C=04,H=000C,R=0000,T=2800,P=00,U=0028 @E,0029,DR,C=04,H=000D,R=0000,T=2803,P=00,U=0328 @E,0045,DR,C=04,H=000E,R=0000,T=0000,P=00,U=01A10C2000089A9EE21115A133333365 @E,0029,DR,C=04,H=000F,R=0000,T=2902,P=00,U=0229 @E,0029,DR,C=04,H=0010,R=0000,T=2803,P=00,U=0328 @E,0045,DR,C=04,H=0011,R=0000,T=0000,P=00,U=02A10C2000089A9EE21115A133333365 @E,0029,DR,C=04,H=0012,R=0000,T=2902,P=00,U=0229 @E,0029,DR,C=04,H=0013,R=0000,T=2803,P=00,U=0328 @E,0045,DR,C=04,H=0014,R=0000,T=0000,P=00,U=03A10C2000089A9EE21115A133333365 @E,0029,DR,C=04,H=0015,R=0000,T=2902,P=00,U=0229
As example, if I only display the conn_handle in the case statement, it can keep up.
Is there an easy way to mod your workspace to have the debug message outputs run in parallel with reception of a burst of many events?
1 of 1 people found this helpful
That's a good point. The debug output in the example project uses the software (bit-banged) TX-only UART component, which is not particularly efficient for smooth non-blocking operation.
If you need to maintain the debug message output and have it run more efficiently, the best solution is to remove the software-based UART TX component and swap in a real SCB (UART) component instead. This component takes advantage of the hardware blocks and can make use of interrupts. If you name the replacement component the same ("UDEBUG"), then the code changes should be minimal. Some of the APIs between the two components are named differently even though they perform similar functions, mainly because the SCB block supports SPI and I2C as well as UART and so requires some way to differentiate between them.
The other change you would have to make in this case concerns the actual pin assignment for the SCB-provided UART TX pin (and newly available RX pin). The SW TX UART pin can be assigned anywhere since it's bit-banged, but the SCB pin assignment is more restricted. You will have to choose one of the available RX/TX pairs and then adjust the jumper wire on the Pioneer kit appropriately from P0 to whatever your new debug UART TX pin is.