Hi, Would you please help check one question for me:
How to measure the batter supply capability? That is to say how to set the battery life measurement?
The measurement is for EZ224110 Module!
I am unfamiliar with the ZMODEM protocol and any encapsulation/compression that may be included or required. The data flow across the BLE connection should be functionally transparent, so that the devices on each end shouldn't care about the physical transport layer being wireless vs. wired since it is abstracted away from the application level.
In case there is a handshaking issue of some kind, one thing you can try is to change CYSPP to use acknowledged rather than unacknowledged data using the .CYSPPSP,F=3. This will decrease the maximum potential throughput, but it guarantees that each data packet is transmitted only after the last one is acknowledged. You can also try .CYSPPSP,F=2 in case the wireless RX flow mechanism is somehow throwing a monkey wrench into things.
Can you provide basic steps for how to replicate your non-working test using Cypress tools or otherwise (ideally) freely available software such as Realterm or TeraTerm? I will be happy to investigate closely with a logic analyzer on two devices to see what is going on and narrow down the possible culprit(s).
Also, Vachel: I recommend posting a new topic for your question, as it does not seem to relate to the original question that Yashu asked.
I use TeraTerm. Set up 2 BLE pioneer kits w/ EZ-Serial modules. Attach both to USB ports. Hold down SW2 and press SW1 on one of the kits to establish link. Open TeraTerm to both units. On Central terminal, choose File | Transfer | ZMODEM | Receive. On Perif terminal, choose File | Transfer | ZMODEM | Send. I use binary option and typ test with sending a .pdf file.
The previous is for no HW handshake.
Hit SW1 on both kits to reset them. On Perif terminal, command STU,F=1. Set Perif terminal to HW handshake choosing Setup | Serial Port. Hold down SW2 and press SW1 on Central kit to establish link. Pull P2.1 (CYSPP) to VCC to put Central into command mode and command STU,F=1. Set Central terminal to HW handshake. Remove pullup from P2.1.
Note that ZMODEM from Central to Perif works (even w/o HW handshake)...but, ZMODEM from Perif to Central does not (/w or w/o HW handshake).
I tried commanding .CYSPPSP,F=3 on the Central, but after removing the pullup.. it doesn't seem to go back to data mode and any characters typed on the Perif terminal generate a 'D' data recv'd event message on the Central terminal. Also, any characters typed on the Central terminal are simply echoed back. So... confused on what to do to get Perif to send a file to Central. [UPDATE: I needed to tie P2.1 (CYSPP) to GND instead of leaving it float.. then it went back to data mode. Note sure why a pulldown was not needed until the CYSPPSP command was sent]
NOTE: I removed R52 & R53 on both CYBLE-022001-00 kits and connected a 4-wire link to FTDI USB 3.3V I/O cables on kit pins P1.4, P1.5, P2.3 and P2.2
[FURTHER UPDATE: It seems that in general ZMODEM from Perif to Central does not work unless the Perif baud is configured as less than Central baud.]
I have run through a number of tests this morning, and I have some interesting results that I'd like to see if you can replicate. I believe the source of the problem most likely comes from improper internal handling of the RX flow characteristic in at least some conditions, with the ~30-second delays between data dumps occurring on the intervals they do because of delayed retry attempts in TeraTerm's ZMODEM implementation.
Try the following setup, intended to have as few modifications from the defaults as necessary to make it work:
- Fresh reflash or factory reset of both test modules
- On the module intended as central, run ".CYSPPSP$,F=0" to disable RX flow usage in the client role
- On the module intended as peripheral, run "STU,F=1" followed by "STU$" to enable and store flow control
- Ensure flow control is now set to enabled in TeraTerm for the peripheral device
- Reset the peripheral module with SW1
- Hold SW2 on the central module's kit and reset it with SW1
- Confirm that the peripheral shows the ".CYSPP,S=01" event and central shows the ".CYSPPSP,S=11" event
- Start sending a file via ZMODEM from the peripheral side
- Start receiving a file via ZMODEM from the central side
Despite no baud rate changes, the transfer should complete about as quickly as possible, with a mostly stable transfer rate of about 11.2 KB/s.
Can you confirm?
I tried the same test without flow control on the peripheral side, and it still worked, though there were some hiccups due no doubt to lost data and delayed retries. After I dropped the baud rate down to 57600 only on the peripheral side, it worked as quickly as expected with very few observed hiccups. I then repeated a similar test with absolutely no changes from the default settings except dropping the peripheral to 57600, and it worked again.
I have confirmed that Perif to Central file transfer now works when Rx flow is disabled on the Central.
If I now set Central baud rate to 57600, I still see assertion of UART_RTS output from the Perif to TeraTerm... and the file transfer still works
Shouldn't that signal be flatlined when the "CYSPP Rx Flow Control" within the Central is disabled?.. or is the Rx Flow from the Central's wired Host disabled?
Can you advise if this issue will be added to the repair list on the next release of EZ-Serial images?
Also, can you answer my other question here:
Thanks for the confirmation. I am investigating the issue this week and will include a fix for it in the next release, assuming it doesn't turn out to be something inherently incompatible between the ZMODEM protocol and the particular UART RX/TX buffer size/threshold. At this point, I expect a bug rather than an inherent compatibility problem.
The UART_RTS signal is logically separate from the CYSPP RX Flow Control signal, although CYSPP RX Flow Control can impact the hardware RTS line in certain cases. The RTS/CTS pins are directly controlled by the UART (SCB) peripheral only when UART hardware flow control is enabled with the system_set_uart_parameters API command ("STU" in text mode). When this is enabled, the RTS pin will remain asserted (LOW) as long as the hardware FIFO buffer has at least 4 bytes of space available. Once this threshold is crossed, RTS is de-asserted (HIGH) until the FIFO is processed via interrupt handling and emptied to at least 4 bytes again. In EZ-Serial, the hardware FIFO is emptied into a 128-byte software buffer, where the data is handed off to the API parser or CYSPP data transfer mechanism depending on which operational mode is currently active.
In contrast, the CYSPP RX Flow Control feature is meant to take care of a different specific case that cannot be handled any other way, even if you have two EZ-Serial modules connected with UART hardware flow control enabled on both ends and the UART hosts are obeying the rules. Assume that the peripheral's external host has de-asserted its own RTS, so the module's CTS signal is de-asserted and therefore it cannot send any data to the host. Any data coming in through the CYSPP data pipe will be buffered (up to 128 bytes), but then new data has nowhere to go and will be dropped. If this situation occurred on the client side, all it would have to do is unsubscribe from notifications/indications to stop incoming data flow. But the peripheral can't force the client to stop writing, since writes are entirely client-driven.
That's where the RX flow characteristic on the server comes into play. If the client subscribes to the RX flow characteristic, the server can push a simple 0x00 or 0x01 byte to tell the client whether it's safe to send more data via CYSPP, regardless of what else might be happening concerning the hardware UART. What is supposed to happen in this case is that the client's RTS pin (if enabled) should mirror the server's RX flow status. It's basically a wireless extension of the server's CTS pin all the way to the client's RTS pin, with a buffer in between to avoid excessive fluctuation during a transfer.
You may be wondering why this would have any impact on a ZMODEM file transfer from the peripheral side, since there shouldn't be any way to trigger the de-assertion condition with a transmission that is almost 100% outgoing data to the central device. It shouldn't, but since disabling RX flow subscription on the client side changes the behavior, there is some interaction somewhere. When I have an answer to this, I will reply again here.
I have identified and fixed the issue. The problem concerned a missing role-specific condition on when and how the RX flow control characteristic should be used. As a result, the central side was obeying certain flow status signals that should have been irrelevant for its role, causing the flow of data to stop unexpectedly.
If you create a support case and reference this forum topic in the description, we can provide a pre-release test image to you so that you can verify that the fix solves the problem on your end as well.
I'm seeing intermittent issue with Central @ 57600 and Perif @ 115200 with HW handshake enabled on both ends. I am not using the command to disable Rx Flow control on the Central. When ZMODEMing from Perif to Central, I am seeing the Perif RTS output get stuck high for 1sec and then the BLE connection between the Central & Perif is broken and blue LEDs turn off.
The file size transfer is approx 380KByte and I see 'chunk' sizes of about 32KBytes going into the Perif Rx (yellow trace) with periodic Perif RTS output assertion (blue trace). Then there is some kind of ZMODEM bi-dir small-packet-size handshake between the 32KByte chunks.
However, see the scope trace where RTS is asserted for appox 1sec and then the BLE disconnect occurs. Note that the issue is intermittent and sometimes the file transfer occurs, but sometimes the hang occurs so you'll need to try it a few times until failure
It has improved alot. However, I did receive one disconnect on 13th try of sending 380KByte file from Perif to Central. I stopped after 20 tries on the next test w/o any disconnects.
However, if I now swap roles and make the 57600 baud be the Perif and 115200 baud be the Central, ZMODEM fails immed when trying to send the first 32KByte block from Central to Perif. Not sure if EZ-Serial is supposed to be able to handle this transfer, but I need it for doing firmware uploads to my device from a smartphone.
Testing of.===> 20170623_ezserial_app_cyble-222014-01_jy_test04.hex
I tested Perif @ 57600 and Central @115200. Enable HW handshake for both.
ZMODEM fails/hangs often when trying to ZMODEM from Central to Perif. The Central BLE-Module UART_RTS Output gets stuck high indefinitely. Blatant failure that's easily repeatable.
Need to reset the Central to restore operation. I did not test Perif to Central transfers since this bug is bad and should be fixed.
Advise if the EZ-Serial image and BLE modules can not perform reliable file transfers since I will need to explore other options soon.
I've reproduced the RTS-high state that you describe here, and it seems to be data-dependent as it only happens with a random binary file and not the 512 kByte repeating "0123456789abcdef" string text file that I have been using.
I am continuing to investigate and troubleshoot on your support case. While EZ-Serial might not have ideal efficiency using ZMODEM due to the limited on-module UART software buffer size and the way ZMODEM packetizes and retries data, all types of data transfer in EZ-Serial with your hardware configuration (namely flow control) needs to be reliable. The problem with RTS getting stuck high is a defect which should not happen, and it will be identified and fixed.