CC3120: Embedded Programming hangs

Robert Chen

Part Number: CC3120
Other Parts Discussed in Thread: CC3220MOD

Hi,

Recently I implement the Embedded Programming functions as described in document SWPA230A. The host MCU can successfully send commands to CC3120 as described in Step 1 to 10. The received responses (Ack and Info) are correct. But it is failed at Step 11 (FS Programming). There is no Ack at all. I have checked the UART data by logic analyzer. They are matched with Figure 16. The only difference is the content of chunk data.

Then, I try to use different chunk size. I have tried 512 bytes, 1024 bytes, 2048 bytes and the original 4096 bytes.

For chunk_szie = 512 bytes, it starts to fail once the accumulated size > 2048 bytes. Here is the log:

CC3x20::embeddedProgramming() program image chunk=0 size=512
CC3x20::fsProgram() accumulated 512 bytes
CC3x20::embeddedProgramming() program image chunk=1 size=512
CC3x20::fsProgram() accumulated 1024 bytes
CC3x20::embeddedProgramming() program image chunk=2 size=512
CC3x20::fsProgram() accumulated 1536 bytes
CC3x20::embeddedProgramming() program image chunk=3 size=512
CC3x20::fsProgram() accumulated 2048 bytes
CC3x20::embeddedProgramming() program image chunk=4 size=512
CC3x20::txCommand() failed to get ack. rc=0

For chunk_szie = 1024 bytes, it starts to fail once the accumulated size > 2048 bytes. Here is the log:

CC3x20::embeddedProgramming() program image chunk=0 size=1024
CC3x20::fsProgram() accumulated 1024 bytes
CC3x20::embeddedProgramming() program image chunk=1 size=1024
CC3x20::fsProgram() accumulated 2048 bytes
CC3x20::embeddedProgramming() program image chunk=2 size=1024
CC3x20::txCommand() failed to get ack. rc=0

For chunk_szie = 2048 bytes, it also starts to fail once the accumulated size > 2048 bytes. Here is the log:

CC3x20::embeddedProgramming() program image chunk=0 size=2048
CC3x20::fsProgram() accumulated 2048 bytes
CC3x20::embeddedProgramming() program image chunk=1 size=2048
CC3x20::txCommand() failed to get ack. rc=0

And for chunk_size = 4096 bytes, it fails from the beginning.

CC3x20::embeddedProgramming() program image chunk=0 size=4096
CC3x20::txCommand() failed to get ack. rc=0

Then, I tried to send GetStatus command after txCommand() failed. There is also no Ack for GetStatus. Obviously, CC3120 hangs after receiving 2048 chunk data bytes in step FS_PROGRAMMING.

The "up-to-date" bootloader is successfully patched to SRAM and SFLASH in step 6 and step 9 using the same txCommand() function. So, the function itself should be no problem.

It is really difficult to debug in this situation. Does anyone has this kind of experience? Any idea is helpful.

over 5 years ago

0 Vincent Rodriguez over 5 years ago

TI__Mastermind 28285 points

Hi Robert,

Let me look into this and get back to you.

BR,

Vince

0 Vincent Rodriguez over 5 years ago in reply to Vincent Rodriguez

TI__Mastermind 28285 points

Robert,

The chunk size needs to be 4096 always. Secondly is your key size 16?

BR,

Vince

0 Robert Chen over 5 years ago in reply to Vincent Rodriguez

Mastermind 9125 points

Vince,

I know the chunk size needs to be 4096. But it is always failed with 4096 bytes. So, I try different chunk sizes to see if any difference.

I don't use secret key at this test, so key size = 0.

0 Jan D over 5 years ago in reply to Robert Chen

Guru 79985 points

Hi Robert,

Just a comment. I use Embedded Programming for for production programming of CC3220MOD devices. My impression from that how Embedded Programming works is not a best. My recommendation is to copy exactly function of python code inside the Embedded Programming package. Embedded Programming is pretty sensitive for timing related issues.

Potential timing related issue can be examined by comparison with original python code. In this case can be COM port sniffer (like old good COM spy) useful.

Jan

0 Robert Chen over 5 years ago in reply to Jan D

Mastermind 9125 points

Hi Jan,

Yes, I design these functions based on the original python code. But my host MCU can't run python, so I design them in C/C++.

The serial port data stream is examined by oscilloscope. This oscilloscope has Logic Analyzer function which has the ability to analyze serial protocol and display RX/TX data values directly on screen. This is how I can compare the data with Fig.16 of the Embedded Programming User's Guide.

When I say "no Ack", it means I can't see any Ack bytes (0x00 0xCC) shown on the serial protocol analyzer. And txCommand() doesn't get Ack, neither. And when the chunk bytes is decreased to 2048 bytes, I can see the Ack bytes for once.

0 Jan D over 5 years ago in reply to Robert Chen

Guru 79985 points

Hi Robert,

I am not able to say why you not get ACK response. We have also written python code into different language (actually into object pascal). My colleague which done this porting had many troubles with this, but he was able made that. Things about ACK to last data chunk is pretty annoying, but seems you are not so far...

Analysing UART communication at logical analyser especially at hardware oscilloscope is generally not a most user friendly thing. From this reason I prefer using PC (e.g. connecting RX, TX lines by diodes and capturing via one UART). We were able to do our porting job by the comparison of data flow with python script.

Are you able program .ucf file with original Python code? If so, my recommendation is to use comparison method.

Jan

0 Robert Chen over 5 years ago in reply to Jan D

Mastermind 9125 points

Hi Jan,

I figured out how to avoid the timing issue about what you said "Things about ACK to last data chunk is pretty annoying". For general slow MCU, there isn't hardware FIFO for UART RX register. So, the incoming data will override the previous data if the read operation is not fast enough. For example, if the application is blocked by an ISR that takes too much CPU time, the previous unread byte on RX register will be override. The trick is to keep UART ISR as simple as possible. And keep other tasks/ISRs from running when executing the Embedded Programming functions.

I get used to oscilloscope and its serial protocol analyzer. With oscilloscope, I can also check if the signal level is correct or noisy. But I can also sniffer TX/RX data by a PC terminal program. But, I don't think there is difference at this moment.

Your suggestion "program .ucf file with original Python" is good. I will try. Just need to jump so wires...

Hi, TI Engineers,

Sometimes TI engineers will request users to log the NWP output at pin 62. I have logged the data from pin 62. Could you please take a look at the log file and give me some advise?

Fullscreen CC3120 NWP.log Download

� -�-1{�(	��	��

�
�	-�-1{�( LS
�
��D(�(����(
1
��

�*��1
�
�	�
�*� �DDh�˯)va*�|�ȩh
�*� x���1��
�	��
<	��
���	��*�1
�
�@��
�@���
�@��D	
�@
�)�
��)� 
� "-�-1{�(	���
�


�
�	-�-1{�( LS
�
��D(�(��8�(
1
��K
�*��1
�
�	�
�*� �DDh�˯)va*�|�ȩh
�*� x���1��
�	��
~	��
���
�!-- 
�@*��
�@*��n
�@

n
n
n
n
�
n
�
�
n
n
n
�	
�
�
�-�-1{�( LSLS 0-
�	-�-1{�( LS��
�
�
n
�
�
n
n
n�!�
�"
�
'�/sys/factory.img
�=��
�
-0-@-P-`-p-�-�-�-�-�-�-�-�-
�#0-�=��n	 �-�=�� Pn

0 Jan D over 5 years ago in reply to Robert Chen

Guru 79985 points

Hi Robert,

By this "Things about ACK to last data chunk is pretty annoying" I mean that after sending last chunk of .ucf file you will not get ACK immediately. You will get ACK delayed according size of programmed image (ACK is returned after is image unpacked and filesystem is created).

I am not sure if NWP log can provide useful information during Embedded programming. I suppose not, but please wait for answer from TI side.

Jan

0 Vincent Rodriguez over 5 years ago in reply to Jan D

TI__Mastermind 28285 points

Hi Robert,

Reviewed the NWP logs, and i don't see any issues. No errors are occurring on the NWP. Please try to default python script and let us know if you still have problems.

BR,

Vince

0 Robert Chen over 5 years ago in reply to Jan D

Mastermind 9125 points

Hi Jan,

Now Python code can program the target CC3120 directly. Phython code can work without problem.

But, I can feel there is ~3 seconds delay after the 1st chunk is sent. And there is ~9 seconds delay after the last chunk is sent. My txCommand() only waits up to 1 second for each chunk and waits 10s for the last chunk (since Fig. 15 shows 8.766s delay for the last one). This is why my program can't work. After waiting for 3 seconds for the 1st chunk. It works now.

I guess bootloader will erase all the serial flash memory when the 1st chunk is received. And the time should be related to the size of flash memory.

Thank you Jan and Vince. You really help me a lot.

Wi-Fi

Wi-Fi forum

CC3120: Embedded Programming hangs