CC2530-ZNP SPI Problem

Pavel Kosenko

Genius 4540 points

Other Parts Discussed in Thread: CC2530, Z-STACK, CC2591

Hi!

We start project use CC2530 with ZNP software and we have same problems.

When I try use Simple_API and interconnect by SPI we have next –

The initialize is right. I get SRSP replay from ZNP(CC2530). The status of replay is right (zero).

When I start stack(the ZB_START_REQUEST{00 26 00} command (I made ZB_APP_REGISTERS_ REQUEST{0D,26,0A,0E,55,55,00,07,01,00,01,AA,00,01,FF,00} early)) I must get from ZNP the firs SRSP and after, my be sometime, AREQ Zb_Start_Confirm (0x01 0x46 0x80 0x00). Like wrote in documentation. I get SRSP replay for both command and two AREQ. The ZDO_STATE_CHAGE_IND (0x01 0x45 0xC0 0xXX) и AREQ Zb_Start_Confirm (0x01 0x46 0x80 0x00). It if device starts correct. But I get this AREQ replays very unstable and CC2530 doesn’t go to “sleep” mode. But I can “see” ZigBee device by sniffer.

All experiments were next configuration 1 coordinator and 1 end device.

This problem is absent with UART. All work properly and stable.

If I try UP AF_Interface the situation is better. But connection to ZigBee network is still unstable. After I send ZDO_STARTUP_FROM_APP APP {02,25,40,00,00} command I get SRSP reply from ZNP but sometime I don’t get AREQ(_STATE_CHAGE_IND (0x01 0x45 0xC0 0xXX)) reply. And device doesn’t go to sleep mode. When I use UART all work properly. This problem only with SPI.

over 14 years ago

0 xyzzy over 14 years ago

TI__Expert 5255 points

Which version of Z-Stack are you using, 2.3.0 or 2.3.1?

0 Pavel Kosenko over 14 years ago in reply to xyzzy

Genius 4540 points

Z-Stack 2.3.1

0 Dirty Harry over 14 years ago

TI__Mastermind 19350 points

The ZNP by SPI transport is working fine. So why don't you try starting with the ZAP - a suite of sample applications using the ZNP - download it from the same place as Z-Stack. This will give you a solid example of how to talk to ZNP via SPI.

0 Pavel Kosenko over 14 years ago in reply to Dirty Harry

Genius 4540 points

Ok! My be SPI works fine.... But i have same question. Why SDRY always in LOW? (The ZAP project. ) I send picture. CH1 - clock of SPI, CH2 - SRDY, CH3- MRDY.

When I start of program the exchange of MSP2618 and CC2530 is good. But after same time SRDY goes to LOW. And You can see this picture. The clock is own time of 30 seconds.

0 Dirty Harry over 14 years ago in reply to Pavel Kosenko

TI__Mastermind 19350 points

SRDY goes low even though MRDY is inactive high when ZNP slave has an asynchronous message ready to send, AREQ. The host must service that AREQ ready according to the RPC protocol by sending a POLL.

0 Pavel Kosenko over 14 years ago in reply to Dirty Harry

Genius 4540 points

You are right! I now it. And I see POLL by oscilloscope, but I don't see reply to POLL from CC2530. This situate for kit very stable.

Is it mistake in example? Or in CC2530?

0 Dirty Harry over 14 years ago in reply to Pavel Kosenko

TI__Mastermind 19350 points

I hope that you are working with un-modified code as you find it from a default installation, otherwise the suspicion will be that there is a mistake in the modifications that you have made. If you are using completely un-modified code, I would like to know about this bug - please describe exactly what code is loaded into CC2530 and MSP, and that steps that lead to the infinite SRDY that you see. Thanks.

0 Pavel Kosenko over 14 years ago in reply to Dirty Harry

Genius 4540 points

Yes! I use un-modified code.

I use software ZNP which I compiled from Z-STACK. One difference switch CC2591 options. (I have EM-CC2530.)

When I start KIT I see same normal requests and after this, about 1 minutes, the kit goes in this condition.

Into MSP I load SimpleExample - coordinator.

MORE! If you want I think I can give you access to my PC in connect oscilloscope to PC and you can see it. I think we can make it.

But to my sorry it is possible only Wednesday. I must back FET. I take the KIT as "renta" and this KIT was without FET.

0 Dirty Harry over 14 years ago in reply to Pavel Kosenko

TI__Mastermind 19350 points

I think that the CC2591 control GPIO confilicts with one of the default ZNP SPI control GPIO's.

You could back out the CC2591 support and you will see this issue resolved. If you must use CC2591, you could try using the UART transport instead of the SPI transport. Finally, if you want CC2591 support and SPI transport, you need to modify the ZNP project HAL to de-conflict the GPIO used for CC2591 and ZNP control; and then build a custom ZNP for yourself.

0 Pavel Kosenko over 14 years ago in reply to Dirty Harry

Genius 4540 points

Thank you! You were right. It was pin conflict.

0 Morten Braathen over 14 years ago in reply to Pavel Kosenko

TI__Mastermind 19525 points

Feel also free to check out our new Wiki on the CC2530ZNP and our new CC2530 ZNP Mini Kit.

http://processors.wiki.ti.com/index.php/Tutorial_on_the_Examples

Enjoy,

LPRF Rocks the World

Zigbee & Thread

Zigbee & Thread forum

CC2530-ZNP SPI Problem