| Author |
Message |
|
|
 Posted: Feb 03, 2012 - 02:07 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
Hello,
I am working on a ZigBee project at the moment. I'm using a proprietary board with the
ATmega128RFA1 as a controller and transceiver. For the first tests I used the MAC-stack from Atmel and the ATmega128RFA1-EK1 Board examples as a sample and adapted it to my hardware. All examples are working fine. Now I want climb the next step and use the ZigBee Pro Stack.
However, I have a problem with the adaption to the hardware and with the documentation. It is not as detailed as it was in case of the MAC-Stack.
One example: I would like to change the pins of the LEDs and buttons. But I cannot find a corresponding file. Does anyone have experience with ZigBee PRO, and can give me assistance.
The MAC stack was documented very well. I was hoping that ZigBee Pro could be handled similar to the MAC-Stack. Or did I miss one chapter in the document?
Thanks in advance. I would be grateful for any assistance!
guitero |
|
|
| |
|
|
|
|
|
|
Posted: Feb 04, 2012 - 06:19 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
| Board specific things are not documented very well in BitCloud. Board specific stuff is located at BitCloud/Components/BSP/*. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 06, 2012 - 09:02 AM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
Thanks for your reply. I found the correct file.
If anyone experiences the same problem: bspLEDs.h in the folder Components\BSP\ATML_STK600\include |
|
|
| |
|
|
|
|
|
|
Posted: Feb 06, 2012 - 05:36 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
@alexru
In some other threads you referred to the Atmel "Low Power" application. Where can I find this one? I downloaded the ZigBee Pro Package BitCloud_MEGARF_1_13_0.It only contains Blink and WSNDemo. I would be glad to have another example. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 06, 2012 - 09:28 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
| Download ZigBit SDK, it includes the most complete set of examples, but it won't have project files, which are really easy to create based on existing projects from the correct SDK. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 08:59 AM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
Thank you alexru!
There are two other problems!
1.
All of my applications need about 25 seconds to initialize. The blink-application for example needs 25 s until the LEDs start blinking. Is there something wrong or just normal behaviour?
2.
I would like to use a button. On my board it is on PB0.
But I don't know what to change exactly. So far I changed the following line in buttons.c
Code:
bspAddButton(BSP_KEY0, GPIO_B0_make_pullup, GPIO_B0_read);
But unfortunately this is not working.
Thanks for your assistance! |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 04:32 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
|
guitero wrote:
All of my applications need about 25 seconds to initialize. The blink-application for example needs 25 s until the LEDs start blinking. Is there something wrong or just normal behaviour?
There is definitely something wrong. Initialization should not take more than 1-2 second in a worst case. What fuse settings do you have?
guitero wrote:
I would like to use a button. On my board it is on PB0.
Default BitCloud code handles only buttons on IRQx pins. PB0 is a PCINTx pin, so you need to trace and change entire chain application-BSP-HAL.
Another way to go is to put ISR for PCINT in your application and don't use BitCloud for this at all. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 04:56 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
What fuse settings do you have?
Fuses that are enabled:
JTAG, SPIEN, Bootflash: 512 address: FE00, EESAVE, CKDIV8, Internal Oscillator.
Extended: 0xFE
High: 0x97
Low: 0x62
Quote:
Default BitCloud code handles only buttons on IRQx pins. PB0 is a PCINTx pin, so you need to trace and change entire chain application-BSP-HAL.
Okay. I'm not sure if I am able to manage that but I'll give it a try.
Thanks for your reply |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 05:02 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
| Fuses look fine. I would assume that something is wrong with the hardware. You need to start at HAL_Init() and see where it spends all this time. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 05:19 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
You need to start at HAL_Init() and see where it spends all this time.
I really do not know how to proceed now.
Would you use a timer for this? I don't know how to start, I'm sorry.
I would appreciate your help! |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 05:23 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
You'll have to use debugger or just light an LED at different points and measure how long it takes for LED to light at different points.
Show PCB design and schematic for your module. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 05:36 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
You'll have to use debugger or just light an LED at different points and measure how long it takes for LED to light at different points.
Can I just take the HAL_Init() function separately without the other stack-Layers?
Quote:
Show PCB design and schematic for your module.
I'm sorry, but a business partner of my technical college developed the board so I'm not allowed to give out the schematics. I still hope that it's not a hardware problem. That would be a huge problem for me. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 05:42 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
|
guitero wrote:
Can I just take the HAL_Init() function separately without the other stack-Layers?
No, it has to be debugged as a part of BitCloud.
Also try to set CS_UID to a non-zero value in the configuration.h first.
guitero wrote:
so I'm not allowed to give out the schematics.
I don't need complete schematics, but I need surroundings of a megaRF and power supply chains. You can send them to my e-mail, if you don't want to share them publicly. Otherwise you on your own, start from CS_UID and proceed to debugging HAL_Init(). |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 05:52 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
Also try to set CS_UID to a non-zero value in the configuration.h first.
It's still the default value, 0x0LL but I also have tried other values.
Quote:
Otherwise you on your own, start from CS_UID and proceed to debugging HAL_Init().
Okay. I'll first try debugging and then post the results here.
Thank you for your great assistance Alex! |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 06:36 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
I used the blink-application for testing. First I added a line to light a LED within the HAL_Init(). But nothing happened. Then I renamed the HALInit.c to test if its acually included. The file is located in Components\HAL\avr\atmega128rfa1\common\src. But the compiler gave no warning during compilation. It is possible to rename all the files that have to do with the HAL-Layer without getting a warning from the compiler. Did I forget an include?
But the application is running as desired. What am I doing wrong?? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 06:38 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
| You need to recompile HAL after any changes by hand. Run "make clean all" form a command line from the HAL directory. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 07:10 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
The first short delay happens within halInitFreq(). But the problems seems to be halReadUid().
Here the results:
halInitFreq(): 4s
halReadUid(): 22s
Big thanks again!! |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 07:17 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
Well, for some reason your MCU is really slow. The only reason why halReadUid() might take that much time is to wait until few bytes are sent over SPI.
Do you have 32 kHz crystal on your board? Stack will try to calibrate internal RC and if you don't have 32 kHz crystal then this calibration will not work. But I'm not sure if frequency can be set that low. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 07:24 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
Do you have 32 kHz crystal on your board?
No, I read the configuration somewhere here in the forum so I chose the internal oscillator divided by 8. On my board is a 16 MHz crystal between XTAL1 and XTAL2. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 07:29 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
| 16 MHz crystal is used by the radio part, your MCU runs on internal RC oscillator. But to calibrate internal RC oscillator BitCloud uses 32 kHz oscillator as a reference. It should be placed on PG3 and PG4. You may work without it, but you'll have to disable calibration in the HAL and you'll probably have troubles with sleeping. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 07:42 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
Okay, and I always wondered why the Atmel EK1 has a 32 kHz oscillator. Maybe I can find a way to upgrade the board with a crystal.
Quote:
but you'll have to disable calibration in the HAL
Which functions are involved?
Last question for today!
Thanks a lot. Have a good evening! |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 07:44 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
| halStartingCalibrate() |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 07:51 AM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
But to calibrate internal RC oscillator BitCloud uses 32 kHz oscillator as a reference.
So would it also be a problem to use USART at higher speeds (>9600 Baud)?
Quote:
The only reason why halReadUid() might take that much time is to wait until few bytes are sent over SPI.
I haven't configured the EEPROM part so far. My EEPROM is on PB4. There is no UID in my EEPROM. Could that also be part of the problem?
I don't understand the selection of Int. RC Oszillator in the Fuses.
Int. RC Osz.: 32kHz
CKDIV: 8 kHz
Result: 4 kHz
The Blink-example demands a 8 MHz system clock. How does that fit with the 4 kHz Clock? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 04:13 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
|
guitero wrote:
So would it also be a problem to use USART at higher speeds (>9600 Baud)?
Yes, it will. Normal UART operation is the main reason for calibration.
guitero wrote:
I haven't configured the EEPROM part so far. My EEPROM is on PB4. There is no UID in my EEPROM. Could that also be part of the problem?
No, SPI will just receive 0 as UID, but it should happen quickly.
guitero wrote:
I don't understand the selection of Int. RC Oszillator in the Fuses.
You have selected 8 MHz internal RC oscillator in your fuses. CKDIV8 will divide it to 1 MHz for easy calibration and after calibration stack will disable CKDIV8. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 04:48 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
You have selected 8 MHz internal RC oscillator in your fuses
Aha, the internal RC is 16 MHz and the Prescaler is 1:2 in the default state, isn't it? Thus it's 8 MHz.
If I use the USART (9600 Baud) with the fuses I have posted above I get wrong output on the terminal. If I change Fuses to the Transceiver Oscillator instead the output is correct. Why can't I use the Transceiver Oscillator. Which part of the Bitcloud won't work? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 04:51 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
|
guitero wrote:
Aha, the internal RC is 16 MHz and the Prescaler is 1:2 in the default state, isn't it? Thus it's 8 MHz.
Correct.
guitero wrote:
If I use the USART (9600 Baud) with the fuses I have posted above I get wrong output on the terminal. If I change Fuses to the Transceiver Oscillator instead the output is correct.
That's because calibration to non-existing 32 kHz made frequency completely off.
guitero wrote:
Why can't I use the Transceiver Oscillator. Which part of the Bitcloud won't work?
Sleeping. RF transmitter frequency is disabled during the sleep. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 05:06 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
Without an 32 kHz Oscillator I can't
1. address an external EEPROM (very slow)
2. use sleeping mode
Is that right?
According to that I have to find a way to upgrade my board. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 05:22 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
|
guitero wrote:
Is that right?
I don't know why SPI is so slow. It should not be this way. I assume something else is wrong and your entire system might run at a very slow speed. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 05:33 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
I assume something else is wrong and your entire system might run at a very slow speed.
Damn! Any suggestions what I can do to solve the problem?
How can I check whether the entire system is affected or not. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 05:37 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
First of all I would try to understand what parts of UID read take that much time.
After that I'd run some code that blinks an LED (not a Blink application, but rather hard-coded while (1) loop and manual delays between blinks and try to estimate expected blink interval and compare it to the actual interval) |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 06:29 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
First of all I would try to understand what parts of UID read take that much time
I think this is the part where the delay (20 seconds) happens.
Code:
// wait for end of action
while(!(TWCR & (1 << TWINT)));
Quote:
After that I'd run some code that blinks an LED (not a Blink application, but rather hard-coded while (1) loop and manual delays between blinks and try to estimate expected blink interval and compare it to the actual interval
It's all fine. I wrote a small application that toggled a LED every second. After that I tried to send one Byte to a terminal every second. I checked Int. OSC. (8 MHz) and Transceiver OSC (16 MHz). I recognized no significant delay. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 06:34 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
| Oh, you have TWI UID enabled. It can cause delays if device is not present. I was looking at RCB version, which uses SPI. Then you'll just need to remove this read. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 06:40 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
Then you'll just need to remove this read.
All right! Can you give me a hint how I can integrate my external EEPROM (CS is on PB4) into the BitCloud. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 06:43 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
| I would just remove UID read from the HAL and read it in the application. This way it will be much easier for you to maintain the code. Just set CS_UID to a read value before starting a network. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 06:55 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
Just set CS_UID to a read value before starting a network.
Sorry, I don't quite follow. CS_UID is the unique identifier for every node. How can that be set to a read value? Would you mind getting more into detail? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 06:59 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
You will read some UID value from the EEPROM; then you need to write this value to UID:
Code:
ExtAddr_t addr;
readValueFromEeprom(&addr);
CS_WriteParameter(CS_UID_ID, &addr);
That all valid if you want to read UID from external EEPROM; if you don't I don't understand what the problem is. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 07:09 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
| Sorry. You've got me wrong. My problem is to change the pin of the EEPROM because on the example board it's not on PB4. But I don't find the file where I can change the pinning. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 07:17 PM |
|
Joined: Apr 15, 2009
Posts: 4985
Location: San Jose, CA
|
|
What example board? STK600-megaRF does not have CS for EEPROM at all.
That depends on what you want to achieve.
My advice: BitCloud is a networking library, treat it as such. EEPROM does not have anything to do with sending data, so just access it as you would without BitCloud around. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 07:22 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
| Okay,I think I can manage that. Thanks a lot for your answers Alex! |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
