I have the Stellaris 2.4Ghz ZigBee Wireless Kit and cannot get the demo application to run.
I've built the zstack_collector code with CCSv5 (Version: 5.2.0.00069)
I've installed the following applications:
SW-DK-LM3S9B96-EM2-CC2520-ZStack-9107SW-DK-LM3S9D96-EM2-8555SW-DK-LM3S9D96-8555I've followed the steps provided in the Readme First manual.
The output I receive from my com port is as follows:
Z-Stack Collector App---------------------========================================Z-Stack LED state change----------------------------------------LED1 is OFF----------------------------------------========================================Z-Stack LED state change----------------------------------------LED2 is OFF----------------------------------------========================================Z-Stack LED state change----------------------------------------LED3 is OFF----------------------------------------========================================Z-Stack LED state change----------------------------------------LED4 is OFF----------------------------------------hold start canceled?
****************************************ASSERTION FAILURE in Z-Stack: C:\StellarisWare\ZStack\Components\mac/low_level/srf04/dual_chip/mac_dualchip.c, 149****************************************
The line of code that's triggering the ASSERT is: /* make sure correct radio chip is attached */ MAC_ASSERT(macSpiReadReg(CHIPID) == CHIPID_RESET_VALUE); /* incorrect radio chip or SPI not operating */
Now searching for this error within the forum suggests that I must have a jumper out of place. I've re-read the readme several times and reviewed my board, but I believe that all jumper are in place.
From review of the pictures from my board, any suggestions as to what I've done wrong?
Thanks
Terry,
I will have to go through a setup here and see if I have the same issue.
Lela
Hi Lela
I've updated my system to the following releases:
and I still get the same ASSERT failure returned.
Terry
For further reference, attached is a copy of my project.
3817.zstack_AssertFailure.zip
Could the problem be rooted in that all the example code was built for the LM3S9B96 and not the LM3S9D96? I did notice this as an issue when I attempted to build the provided examples. I had to made several small updates in the search path and re-pathing to the needed drivers to get the code to build.
Terry Biberdorf The line of code that's triggering the ASSERT is: /* make sure correct radio chip is attached */MAC_ASSERT(macSpiReadReg(CHIPID) == CHIPID_RESET_VALUE); /* incorrect radio chip or SPI not operating */
The line of code that's triggering the ASSERT is: /* make sure correct radio chip is attached */MAC_ASSERT(macSpiReadReg(CHIPID) == CHIPID_RESET_VALUE); /* incorrect radio chip or SPI not operating */
If the ASSERT fails, that means macSpiReadReg(CHIPID) is returning some value other than CHIPID_RESET_VALUE
So, what value is it returning?
macSpiReadReg(CHIPID) calls spiSendBytes(&buf[0], len) which returns a value of 0xFF.
so what does a return value of 0xFF from spiSendBytes() signify?
In trying to get a setup going, and have run into fundamental issues of missing kit parts. Have you made any code modifications or board modifications? I am still going through and trying to validate what you are seeing...
My first guess would be that the SPI port is not communicating. Bases on the pictures of my lab setup, can you tell me if I have a jumper in the wrong spot?
I have made no board modifications. I did rebuild my project to the most recent version available. (I did link my project to this forum, please see earlier post)
From the provided project code, I did find that the example project would not build until I updated to match my LM3S9D96. The example code appears to be built for the LM3S9B96 development board.
The example was built for the LM3S9B96, but it shouldn't make a difference. It should have also been tested when we released to the LM3S9D96 kit...Unfortunately...I haven't been able to verify that either.
To eliminate the SPI connection, you can download stellarware example sd_card and see if that gives any errors. If yes, then it is likely the cause.
I have looked at your picture, it appears that you have all of your jumpers correct. Do you have the CC2530EM nodes running? Does the LCD display anything?
Terry BiberdorfMy first guess would be that the SPI port is not communicating
Well, that is one of the 2 possibilities specifically noted in the code you posted earlier:
Terry BiberdorfThe line of code that's triggering the ASSERT is: /* make sure correct radio chip is attached */MAC_ASSERT(macSpiReadReg(CHIPID) == CHIPID_RESET_VALUE); /* incorrect radio chip or SPI not operating */
So, I would suggest that you step through that code to see exactly where it is failing; ie, is it reading a wrong "CHIPID", or is the read failing completely?
You've already noted that spiSendBytes() returns a value of 0xFF - is that the expected return code?
Have you checked SPI operation on an oscilloscope?
I was able to run the sd_card demo without any problems.
I will step through the code as suggested. I will also review the schematics for the expansion board to determine if the SPI communication is getting to the zigbee module.
Sheck the SPI lines on an oscilloscope.
Andy NeilWell, that is one of the 2 possibilities specifically noted in the code you posted earlier: Terry BiberdorfThe line of code that's triggering the ASSERT is: /* make sure correct radio chip is attached */MAC_ASSERT(macSpiReadReg(CHIPID) == CHIPID_RESET_VALUE); /* incorrect radio chip or SPI not operating */
Note to TI:
Double-meaning errors like this are really unhelpful!!
The ASSERT should really distinguish whether it's a comms failure, or a wrong-value.