MC13213 communication stops

[tommasosinico]

Hello, it's Tommaso from Italy again

I'm working on my thesis,  and i'm trying to program the MC13213 boards.

I made two devices talk with each other, transmission consist of a packet with constant length payload sent every 3 seconds. I'm not sure i made them communicate correctly (i have read the manuals but i'm still not sure, please see https://community.freescale.com/message/369888#369888) but now the problem is that after a certain period of time the communication stops!

I suppose i used uncorrectly some register or something and a memory overload occours!

I really don't know where to start and what to check first.

I really appreciate any help you can provide.

With best wishes for a Happy New Year.

Tommaso

[iansmusical]

Hi Tommaso,

It sounds like you've made a lot of progress since your last forum posting :-)

Firstly I don't have any experience of the BeeStack but I'm sure there will be people on here that do and they can quickly point you in the right direction. The example that you are using, however, should give all you need to establish the RF link? I would suggest making sure you fully understand the example and what the relevant API's do before you start to customise the software for your needs.

Now you need to be logical in order to address the issue you are having. Does it repeatedly fail after a fixed time? Are you able to use the debugger to see if it's the transmitter or receiver that stops working. What is the code doing in both modules at the failure point? It is sometimes also easier to go back to square one and just do the bare minimum to establish an RF link, no fancy features etc. Then once you've seen this reliably and repeatedly work move onto the next feature addition. Otherwise one is trying to debug/prove many things at the same time and who knows which one of them might not be working correctly etc!

I believe that you can use the RTI module to wake the MC13213 from a low power mode, transmit your message and then go back to sleep. You'd perhaps be wise to sort your current issue before starting this functionality and then it might be better to prove you can enter and resume a low power mode before you add in all your RF related code. This minimises your changes and possible debugging time.

Hope this helps.

Happy New Year :-)

Ian

[tommasosinico]

Hello Ian,

first i want to thank you for you answer and for the patience. I'm sorry i didn't answred sooner but i was stucked with the "analog" part of my thesis :smileyhappy:

Never mind about the first question, i solved it and communication doesn't stop any more.

Till now i have used a timer to send periodically a message but the low power mode didn't work this way. I think i should use the RTI module but i don't know how! Can you help me somehow? Is there a user guide or something? i just looked in my documentation but i haven't found anything

thanks again for the support

Tommaso

[iansmusical]

Hi Tommaso,

What was the issue that was causing your transmission to stop after a fixed amount of time?

For the RTI have a look at this document. It talks about and shows an example of using the RTI for a particular HCS08. Therefore, you may need to adapt it to suit the HCS08 on the MC31213:

http://cache.freescale.com/files/microcontrollers/doc/user_guide/HCS08QRUG.pdf

It doesn't look complicated to use but make sure you understand all the details to save you having problems later!

Hope that helps :-)

Ian

[tommasosinico]

Hello Ian,

thanks again for answering, it seems nobody else is still interested in MC13213 programming..probably it's an outdated technology

I tried to use an other "paradigm" of programming instead of using timers to send messages: i tried to use a state machine with the the task scheduler wich was already working in the accelerometer example code, but something went wrong. I made a measure with an amperometer and the current consumption during the idle time was about 60mA!!! suppose the program went in an infinite loop wich "stressed" too much the MCU so i went back to timers.

Thanks a lot for the document I will try as soon as possible to implement that method!!

I have another doubt : could you explain me what is the polling? cause even if I use timer without low power mode I doscovered that i cannot control everithing that happens during the communication. For first i establish the network than i simply send a message from the ED to the master using a timer. But after every message the board send another message and i found out that is because of polling but i can't understand why!

I'm very grateful for your help

Tommaso

[iansmusical]

Ciao Tommaso,

Admittedly I've not heard of the MC13213 before but it's perhaps considered more specialized having an RF part integrated. However, it uses a general HCS08 core otherwise.

There is nothing wrong with experimenting with different ideas but given you are wanting to send a message every x milliseconds or whatever, then a timer based system is what you require. A state machine while useful would be too much overkill to achieve what you are wanting. The idle consumption of 60mA does sound a lot but strangely a program in an infinite loop won't use any more current then if it was executing other code! Maybe the RF unit was powered up constantly instead of being turned off until you needed it?

Apologies if I've misunderstood you here but I'm not sure polling is the question you mean to ask? However, polling is where, for example, you read an I/O port pin every x milliseconds or constantly to see if it's a 1 or 0 or changed etc. The alternative is an interrupt whereby that same I/O port pin generates an interrupt (interrupts main program flow) when its value has changed. Obviously the latter frees up the micro-controller to do other things.

I wonder if what you are experiencing is that your RTI/timer interrupt is occurring too often? For example, if it takes 50mS to set up a network and 20mS to send a message then there is no point your RTI/timer interrupting in a period of less than 70mS.

Can you explain what is being polled to cause another message to be sent? My understanding is that you simply send a message every time the RTI/timer period expires?

Happy to help :-)

Ian

[tommasosinico]

Hi Ian,

i decided to try using a state machine because the code I used as example (beestack accelerometer) use that principles. I probably wrote a wrong code, could be that Rf module is always on, i'll check for it.

The accelerometer code consumes 17mA when on sleep and has a peak current of 30mA during transmission which seems reasonable.

yes, i didn't know what polling is. Now it's more clear, but i can't understand why non-low-power-mode needs to poll. Furthermode if i use timers i cannot use low power mode at the same time, so timers are not the solutions.

By the way, yes i just send a message every time the timer period expire.

why did you say tha state machine paradigm does not fit my problem?

ps: sorry for my english, i hope i am clear :smileyhappy:

[iansmusical]

Hi Tommaso,

Admittedly I've never used an accelerometer but I would expect an S08 to be using less than 1mA when sleeping, so 17mA seems quite large. 30mA transmitting RF is reasonable.

You said "but i can't understand why non-low-power-mode needs to poll". Can you explain what is being polled, do you mean a register or variable etc? It is perfectly feasible for a timer whether in non low power mode or low power mode to poll something. The RTI timer can be used in low power mode to wake the chip from sleeping to do something and the return to sleeping. You can't however use the TPM timers in low power mode.

I wasn't ruling out a state machine paradigm but from my understanding of what you are trying to do, which is just to transmit a message every time the timer expires, then a state machine isn't necessary. One just needs to write code to transmit when the RTI timer interrupt occurs.

State machines are useful if you're doing many things or wishing to keep the state between operations. For example, you can use a state machine to decode a RF input. Say a state for the preamble, a state for the CRC, a state for the message etc and obviously move between states when receiving. A state machine could be used to keep the state of something between wake up and sleeps in low power mode.

Ian

[tommasosinico]

Hi Ian,

About polling : if use a timer, when timer period expires the node send a message to the master. Then few milliseconds after node sends another message which i can't explain. I looked for an explanation in the code and i found this :

/*Default Timer Value for Time Between the confimation received for any

    request and the next poll request sent by an End Device

    ( The value is given in millisecond )*/

#ifndef mDefaultValueOfConfirmationPollTimeOut_c

   #define mDefaultValueOfConfirmationPollTimeOut_c  200      

#endif

analizing the consumption signal with an oscilloscope i measured exactly 200 milliseconds between the two messages. So the node needs to poll the master, right?

About the consumption : at the moment i'm using the accelerometer code without any modification. That code use the state machine paradigm. I want estimate the RF consumption so at the moment the MCU consumption it's non influential.

I have another question: how can i use the GPIO of the MCU? I need to know the Rf power on interval, so i turn on a led when the "TxRx_enable" function is called and i switch it off when the "TxRx_disable" function is called. I'd like to use another port bacause led consumes a little current.. is it possible?

Again, thanks for your answers.

Tommaso

[iansmusical]

Hi Tommaso,

Hmm... not sure if I am understanding. Are you saying that a message is sent every 200mS from the node to the master? Or a message is sent and after 200mS the master acknowledges it, thus the node must be awake to receive the acknowledgement? Or a message is sent and after 200mS the node polls the master for something? Does the master acknowledge the node, that is, send a reply? If it does then this would indeed mean waking the chip with the RTI to send a message would need more thought, as it would also need to be awake to receive a message.

How are you measuring the current consumption of the RF part? Does it have a separate power supply to the HCS08 core?

Each 8 bit port on the MCU should be able to supply something like 10mA-30mA in total. Therefore, you can increase the resistance that is connected to the LED you are using to reduce its current to say 4mA. That will enable you to use another pin on the same port (careful when you turn the LED on/off that you don't interfere with the other LED). Alternatively you can just use another port in exactly the same way as you've done for the other LED. You'll obviously need to set up the data direction register for that port and then write to the data register for that port.

Ian

[tommasosinico]

Hi Ian,

I think I wasn't clear. I'm talking about two different code files.

The first one uses a timer (so not LPM) and send messages when the timer period expires. So Rf module is always on. (I'm working with the second code not with this, because RF is always on indeed). I just wonder why i see two peak consumption of the node with the oscilloscope. Let's suppose that timer period is 1second. On the oscilloscope there is a peak consumption every second AND another peak consumption 200ms after every message.

The second one is the original accelerometer example from freescale. I'm using this code fom the current consumption measure. I will send you a schematic as soon as i can. I didn't know about the direction register! I'll look for it, thanks!

Just another little problem, i cannot figure out what function is used to turn on/off the RF module. Any ideas?

Have a nice day,

Tommaso

[iansmusical]

Hi Tommaso,

Ah ok I think I am understanding you better now. So a message is transmitted every time the timer period expires and then always after 200mS something else is transmitted or received? My feeling is that the master is acknowledging the node's transmission! It presumably isn't possible for the node to transmit other than every time the timer period expires? Maybe you could add a check of a receive/acknowledge register or maybe an interrupt can be configured to fire upon data reception?

Here is some information about I/O pins and their respective registers taken from the reference manual: http://cache.freescale.com/files/rf_if/doc/ref_manual/MC1321xRM.pdf

  "port A data (PTAD), data direction(PTADD), pullup enable (PTAPE), and slew rate control (PTASE) registers. Refer to Section 13.4, “Parallel I/O Controls”, for more information about general-purpose I/O control."

Obviously there are ports A to G that are usable and I'd imagine your Tx/Rx LED is already on one of them. You simply need to configure a suitable pin as an output, connect your LED to it and then write to the PTxD data register etc.

You need to look at Chapter 7 in the above reference manual for the RF module. It appears that a simple on/off state is not possible. However, there are several supported states from fully active to fully off. Each have advantages and disadvantages and the chapters talks about them and how to move between them. It doesn't look simple as such! Hopefully there is some example code like, for example, the accelerometer that you can use?

Ian

[tommasosinico]

Hi Ian,

It probably work as you said but I won't work with timer because LPM cannot be used.

I found the I/O ports definitions and usage in the code, the manual you sent to me is really useful, thanks! much better than the one i have.

Fortunately LPM is already implemented by freescale in the accelerometer code, i'm tryng to figure out how to use it.

Unfortunately i figured out that i don't completely understand how to send a message correctly. I'm working on it. I will let you know!

Thanks a lot for the help given

Tommaso