µTasker Forum

µTasker Forum => NXPTM M522XX, KINETIS and i.MX RT => Topic started by: intern on September 26, 2012, 02:49:53 PM

Title: uNetwork receive
Post by: intern on September 26, 2012, 02:49:53 PM
Hi

I am trying to communicate between two boards with uNetwork.
One of the boards transmit, while i look at the other with debugger with breakpoints.
The transmitter board i have setup, but i am not sure how to set the other up. I have used the documentation for uNetwork.

i am using single address and i don't know how i can see that a board have received something from the other board and how i can see on the board sending that the data was not received.

I use wireshark to see the communication, CW10.2.

Which function is called when a frame is received?



Regards

The Newbie
Title: Re: uNetwork receive
Post by: mark on September 27, 2012, 02:21:39 PM
Hi

The first thing to do is to watch the uNetwork frames being sent using Wireshark. If you are sending broadcast frames there will be just one transmission but if you are sending to a specific destination you should should see some repetitions, assuming that the receiver is not responding to them. If the receiver is correctly receiving it wil acknowledge them.

Check that the destination MAC adress corresponds to the MAC address of the destination card and correct it if not since the destination will otherwise not receive it.

Also check the protocol being used - both nodes should be using the same value.

Any Ethernet receptions to the correct MAC address aand with the correct Ethernet protocol (uNetwork value) will pass through the routine
extern void fnHandle_unet(unsigned char *ucData)

Therefore you can first set a break point in here at the receiver and it should be hit each time a uNetwork frame is received.

Regards

Mark
Title: Re: uNetwork receive
Post by: intern on October 02, 2012, 02:46:05 PM
Thanks..

Now i just have another problem.

I have these two boards. The transmitter board sends to the receiver board and the receiver board ACk it. That is what i see in wireshark.
My problem occur when the transmitter board needs to send a second frame to the receiver board, in my code i can see it calls the function and gets though it as nothing is wrong, but if i look in wireshark nothing happens.
If i restarts both boards it does the same thing.
If the receiver board isn't connected, the transmitter board sends it a lot of times.

Hope you can help me..
Title: Re: uNetwork receive
Post by: mark on October 02, 2012, 04:58:58 PM
Hi

You will need to see what fnDistributedTx() is doing. It works once and it is also possible to send additional messages before the first one is acknowledged (up to the limit of queued messages defined by MAX_STORED_MESSAGES).

There are several reasons why there may be no transmissions:
- first of all, if you send to a task that is local (and not remove) it will simply deliver locally and you won't see anything
- then, there are a few reasons why the routine would not send (see the return 0 cases in it)
-- like invalid destination node, invalid destination MAC address, which could be configuration errors
-- also check that the length of the data sent is not greater than MAX_UPROT_MSG_SIZE

What happens if you send exactly the same message more than once - this should each time be sent identially.

Regards

Mark
Title: Re: uNetwork receive
Post by: intern on October 03, 2012, 08:34:25 AM
Hi

I am trying to send the same message again and again, but after it have send the first and received an acknowledge it can't send to the same MAC-address. If i try to send the same message twice to the same MAC-address it only sends the first if it gets an acknowledge, if i then try to send global or to another MAC-address it those that fine.
The communication is between to boards on the local LAN network.

For the two boards to communicate again i need to restart both boards.

Title: Re: uNetwork receive
Post by: intern on October 05, 2012, 07:30:12 AM
The attached file shows what i see in Wireshark when i try to send four messages to '02' from '01'. i am trying to send them more than ones, but as you can see they only appears  ones

This is the code where the function is called.
Code: [Select]
if(count1 == 3){
fnSendMessageG(102,2);       
fnSendMessageG(102,2);
fnSendMessageG(90,2);
fnSendMessageG(40,2);

count2++;
}
if(count1 == 5){
count1 = 0;
}
The function is made from the documentation for uNetwork for single address.

I have looked at the 'return 0' in uNetwork.c, i have also gone though fnDistributedTx() in debugging mode but can't see anything wrong in it..
Title: Re: uNetwork receive
Post by: mark on October 06, 2012, 06:46:53 AM
Hi

Your code shows that you send 4 message immediately after another. The image from your Wireshark recording shows 4 Ethernet frames being sent from MAC 00-00-00-00-00-01 to MAC 00-00-00-00-00-02 and 4 acknowledgements being returned from MAC 00-00-00-00-00-02. This all takes place quickly, with all 4 messages being acknowledged within about 300us.

When you write that they only appear once do you mean that all 4 only appear once?

From the code that you show it is not clear that they are sent more than once - will all 4 be sent periodically? If so, how often?

Since this shows 4 messages being sent to the same MAC address, could you explain why you write that you can send only 1 to a particular MAC address?

At the moment the recording matches up with the code that you have shown.

Regards

Mark

P.S. It may be better to upload Wireshark recordings as *.pcap files since it is then possible to also see the data and any other details that could be useful when analysing them.

Title: Re: uNetwork receive
Post by: intern on October 08, 2012, 07:54:42 AM
Hi

yes i mean that it only are the 4 that appears once(wireshark 01-02).
In the code it comes into this 'if' every 10 sec, but i only get these 4.
I can only write once because if the messages isn't send right after each other they never gets send.

The problem is more visible when i use this code:
Code: [Select]
if(count1 == 3){
fnSendMessageG(102,2);       
fnSendMessageG(102,2);

count2++;
}
if(count1 == 5){
fnSendMessageG(90,2);
fnSendMessageG(40,2);
count1 = 0;
}
Here only the first 2 is in wireshark (01-02-2.pcapng)
I can see that the code is used but nothing comes out of the last 2 fnSendMessageG
Title: Re: uNetwork receive
Post by: intern on October 10, 2012, 08:21:52 AM
Hi

I have been working on solving the problem, but i just can't see why it goes wrong.

The code under here is what i am trying to get to work (try21)
Code: [Select]

                static count1 = 0;
                if(count1 == 3){
while(count2 < 8){
         fnSendMessageG(102,2);       
         fnSendMessageG(102,0);
         fnSendMessageG(90,2);
         count2++;
}
}
if(count1 == 5){

fnSendMessageG(40,2);
count1 = 0;
                        count2 = 0;
}
count1++;
}

but as you can see on the attach files not all the messages are getting send. And when i wait a bit longere the only messages getting sent is the global messages.


if i change the code to (try22)
Code: [Select]
static coun1 = 0;
                if(count1 == 3){

fnSendMessageG(102,2);       
fnSendMessageG(102,0);

}
if(count1 == 5){

fnSendMessageG(40,2);
fnSendMessageG(90,3);
count1 = 0;

}
count1++;

Do you have any idea what is wrong?
As much as i can see something goes wrong when it gets an ACK, but what i can't see..
Title: Re: uNetwork receive
Post by: mark on October 10, 2012, 11:14:08 PM
Hi

This is a bit of a mystery since it looks as though when you send to a non-existent address there are a number of repetitions (50ms interval) and you can then send to that address later, as you can send global messages. Once a destination has acknowledged you can't send any more to that destination.

uNetwork.c has been used for several years (in equipment installed in many locations in the world and used intensively - running on the ATMEL SAM7x) and hasn't been modified since 2008 since it has been working correctly. I don't see that it is hardware dependent in any way but there may be an issue with the Coldfire or the compiler. You could try disabling compiler optimisation just to see whether there happens to be a change in behaviour. Also note that there are some counters that can be accessed using fnGetuNetworkStats() which may show up something that aids in understanding what is happening.

If you don't make any progress please send me a zipped copy of the project (make sure that there are no .exe or .bat files as content since they will probably cause the email to be blocked) - probably it is adequate to send just the file in the application directory so that I can build it here with the same compiler and see exactly how it is configured. Assuming that I get the same behaviour I may be able to debug it more efficiently.

Regards

Mark
Title: Re: uNetwork receive
Post by: intern on October 11, 2012, 09:01:55 AM
Hi

I have tried what you have suggested but no change..

mail it to you, yes that can i do.. Which e-mail?
(I have sent it to info_uT@utasker.com, it was the only mail address i could find)
Title: Re: uNetwork receive
Post by: mark on October 11, 2012, 11:46:17 AM
That is OK - it has been received.

Regards

Mark
Title: Re: uNetwork receive
Post by: mark on October 13, 2012, 09:22:44 PM
Hi

I have now had the opportunity to do some tests with the M52259 and CW10.2 (I also compared with CW7.2 with no differences found).

It was not possible to use your project directly since I couldn't get it to build. I think that it would have been necessary to send the entire project, including CW10.2 settings etc. since there were various things missing.

However I did equivalent tests using the uTaskerV1.4 project doing something similar.

In your test  (try21) I think that it is clear why not all messages are being sent due to the fact that you are sending 24 message (in the x8 loop) very quickly and there are not enough buffers available (limited by #define MAX_STORED_MESSAGES      10). This means that not all can be sent since they have no retransmission buffer space. The global messages do get transmitted since they don't require a backup (never repeated) so they get out whilst the later unicast messages have to be dropped.

I concentrated on your (try22) test. The Wireshark recording is attached with 2 nodes (1 and 2) doing the same test every 10s (in both directions). At the start only one node is powered so the first test transmissions repeat until they give up. After that all looks correct. The messages sent between nodes 1 and 2 are correctly acknowledged and the ones sent to node 3 (didn't exist) are repeated a few times before they give up. It was not possible to reproduce your problem with transmissions stopping after messages had been acknowledged once. I tried various permutations to see whether there was one that could cause problems but I never had any issues after spending over half a day of expermenting.

My conclusion is that you may have a problem due to something outside of this module in your project so I would carefully check the amount of memory the project is using to see whether there could be a memory shortage causing something to get corrupted. I would also suggest repeating the tests based on the uTaskerV1.4 project without other changes to verify that you can reproduce the correct operation before moving to the final project again. Below is the code that I used based on your transmission subrouting - note that I control the periodicity of the test also at this location with the timer calling the test again each time that it fires.

There was however a modification that I made to the uNetwork.c file due to the fact that I was losing synchronisation (acknowledgement counter) when sending immediately after reset before the Ethernet link was up (and thus losing the first test messages). In the main project using this the case is never encountered so I didn't realise that this coudl happen. I don't think that it is releated in anyway to the difficulty that you have had since it has nothing to do with transmissions.

My most up to date file is also attached including this change as reference.


Code: [Select]
static void fnSendDist(void)
{
    fnSendMessageG(102,2);
    fnSendMessageG(102,0);
    fnSendMessageG(102,2);
    fnSendMessageG(102,3);

    uTaskerMonoTimer(OWN_TASK, (DELAY_LIMIT)(10 * SEC), SEND_AGAIN);
}

The timer event simply calls the test again:
            ...
else if (SEND_AGAIN == ucInputMessage[MSG_TIMER_EVENT]) {
                fnSendDist();
            }


Note that the destinations are reversed at each nodes (as you will already be aware of) so that they sent to each other.

Regards

Mark
Title: Re: uNetwork receive
Post by: intern on October 23, 2012, 09:22:25 AM
Have there been any changes that can affect the problem from the uTasker v1.4-0 to a newer version because i use uTasker V1.4-0?

I have sent my project to you, because i have worked with it the last days but i haven't come any nearer i solution.
Title: Re: uNetwork receive
Post by: mark on October 23, 2012, 02:50:06 PM
Hi

There had been no changes related to the uNetwork since 2008 (V1.4-0 dates back to August 2009).
In the meantime I have received your complete project. However I don't find a CW10.2 project in it - are you using CW7?
Please could you tell me which is the project file that you open? Is it Firmware 2.5.1\Applications\uTaskerV1.4\CodeWarrior_M5223X\uTaskerV1.4_CW7.mcp ?

Regards

Mark
Title: Re: uNetwork receive
Post by: intern on October 23, 2012, 02:53:31 PM
I am using Firmware 2.5.1\Applications\uTaskerV1.4\CodeWarrior_M5223X\uTaskerV1.4_CW7.mcp but i am using 10.2.
I have importet project from the CW7 into the CW10.2.
 
Title: Re: uNetwork receive
Post by: mark on October 24, 2012, 04:36:33 PM
Hi

I am sorry but after spending another half a day trying to get the project to run on an M52259EVB it still won't start due to missing HW. This means that I would need to rework the project to get to a point where the tests could start. The code is rather large with many additional modules so I don't know what I can remove and whether they would cause the effects that you are seeing to change.

Therefore I would like to suggest that you start with the V1.4 project (either the latest version or the version that your project is based on) and add the simple task that you are testing to see the effects. If you have the same effects running on a DEMO or EVB it would then be possible to test it here. Note that this is effectively what I already did and tested it with CW7 and CW10 without finding any problems.

Also, if you get the problem, I would recommend setting a break point on the call that is trying to send the message and step into the functions to see whether you can identify why it is not sending it. This can be compared with what it does when it does successfulyl send it, which should lead to identifying what can go wrong.

Regards

Mark
Title: Re: uNetwork receive
Post by: intern on October 25, 2012, 09:00:05 AM
Hi..

Thanks for the try.. and for the advise..

So now i am trying to get it to work with the latest version uTasker project..
So i will get back when i know more..

Title: Re: uNetwork receive
Post by: intern on October 26, 2012, 01:22:24 PM
Okay..
So now i have tried some time to get M52259DEMOkit to work.
The problem is not the uTasker ;D because i haven't come that fare...
i'm trying to get CW v.10.2 to recognize the board, but there comes trouble..

I can't get CW to find it in the debugger configuration..

I know it is not the right place for this question but i hoped someone might have a clue.

'connection type': P&E ColdFire...
'Interface': USB Multilink, Embedded OSBDM - USB Port
So in 'port' nothing is detected..  ???
Title: Re: uNetwork receive
Post by: mark on October 26, 2012, 02:29:36 PM
Hi

Probably the most freightening parts of using CW10.2 is when one wants to debug or load code and finds that the debug target is not configured. This requires a debug/connect/run target to be created which involves a number of steps and looks horribly complicated.

Fortunately if one remains calm and - can compare with a reference in case of doubt - it is not necessarily as difficult as it first looks.

To load and debug the target I tend to do the following:
- in the project window expand the directories to go into Applications\uTaskerV1.4\KinetisCodeWarrior\MK60N512VMD100_xxx (or where ever your target is using) and click on the output .afx file (eg. uTaskerV1.4.afx)
- right click to get a context menu and select "debug as | debug configurations..." There you can enter a "CodeWarrior download"
configuration - matching your debugger and target processor and then it will load and allow debugging. Again this looks very complicated but it is quite easy to learn how to enter one, which will them be saved locally so that you can simply click on the debug button to used it.

CW10 includes drivers for OSJTAG, JLink and P&E so these do appear as an option at some point in the process.

The Flash programmer in CW10.2 is also useful for downloading code when not debugging. This also has one of these horribly complicated looking setups (for each processor target) but proves also not be to as bad as it first looks when worked through logically.
Often the target processor needs to be entered, or changed, and this can cause problems since it requires you to point to an XML file. Sometimes the directory that is opened when doing this is the correct location with a lot of XML files for the various processor types but sometimes it opens up somewhere else - in the second case one can spend quite a lot of time trying to locate the directory with the files in since they are low down in the Freescale CW file structure. I often have to resort to a file search to find them each time it happens but this is where they are probably located (also saves me having to do this search anymore) -
C:\Freescale\CW MCU v10.2\MCU\bin\plugins\support\TargetTask\Flash_Programmer\ARM for Kinetis
C:\Freescale\CW MCU v10.2\MCU\bin\plugins\support\TargetTask\Flash_Programmer\ColdFire for Coldfire

Regards

Mark


Title: Re: uNetwork receive
Post by: intern on October 31, 2012, 12:03:41 PM
Thanks now i can program the board

So now i have programmed a demo-board(M52259DEMO-kit) with a clean uTasker, with the little modification of uNetwork. I still use the other board with the modified version of uTasker.

I have the same problem , as the one I started with, is still here. I have tried both with the new board as receiver and transmitter.

If i setup rs232 on both boards i can see that both boards act like they receive and transmit correct.
If i disconnect one of them the other stops receive, and vice versa.
On the receiving end  the "fnInterruptMessage(UNETWORK_MASTER, UNETWORK_SYNC_LOSS);" is called after the first time the receiver send an ACK.

Right now i don't have the opportunity to test with two demo-boards with a clean uTasker.
Title: Re: uNetwork receive
Post by: mark on October 31, 2012, 02:01:19 PM
Hi

Make sure that you try with the modified uNetwork.c that I posted earlier in the thread. I also had a problem with the UNETWORK_SYNC_LOSS due to the fact that the first transmissions were made before the Ethernet link was up. With the modification it re-synchronises in thsi case and then shouldn't have this potential problem.

This is however a reception side problem and not a transmission side problem as you were describing before.

Regards

Mark

Title: Re: uNetwork receive
Post by: intern on October 31, 2012, 02:37:05 PM
Alright, then i am trying that..

So now I have tried it with the modified uNetwork, but unfortunately it gives no change in the behavior for the receiver.
Title: Re: uNetwork receive
Post by: intern on November 01, 2012, 01:18:09 PM
I can see in both transmitter and receiver that it looks like they are communicating.
In the receiver i can see that the ucData[1] are counting up, and if i restart the receiver the next ucData[1] has counted without the receiver being there.
Lets say that ucData[1] = 10 and then the receiver restarts. So next time the receiver calls fnHandle_unet the ucData[1] = 15.

This indicate that they are communicating or those it? ???

If this indicate that, then why can't i see it in wireshark?
If not, where is ucData[1] getting that number from??
Title: Re: uNetwork receive
Post by: mark on November 01, 2012, 02:31:25 PM
Hi

ucData[] is the payload received in an Ethernet frame. The value read by the receiver must therefore be due to a reception with this content.

The transmitter will increment the counter for each message (it counts from 0x01 to 0xff and then overflows back to 0x01 - 0x00 is used only by the very first transmission after a reset to indicate that the receiver should resynchronise its counter instead of it being due to a lost frame).

If the transmitter repeats frame transmissions the counter will be the same in the repetitions to indicate that the receiver can ignore it if it has already received a previous transmission of it.

If the transmitter repeats a frame a maximum number of times without receiving an ACK it will increment the counter for the following transmission - that means that it is possible for the transmitter counter to increment when there is no receiver.

When a receiver detects a 'jump' in the transmit count value it known that there was a problem (a transmission and its repetitions were probably lost) and this also results in the receiver declaring a 'loss-of-synchronisation' error.

Regards

Mark
Title: Re: uNetwork receive
Post by: intern on November 01, 2012, 02:38:22 PM
So for the receiver to increment the value in ucData it most have received new data from the transmitter?
Because my problem it still that i can't see (in wireshark) that the transmitter transmit after it gets the first ACK.

Title: Re: uNetwork receive
Post by: mark on November 01, 2012, 11:59:50 PM
Hi

If your HW receiver is seeing frames with incremented counter in the payload it must be receiving these frames.

Are you viewing the Ethernet (with wireshark) behind a switch which is maybe only showing the first data transfer until it knows where both ends of the connection are situated?

This may explain why you only see the first data exchange, why you see broadcasts (switches send these to all ports always) and then no more.

It is best to use a hub rather than a switch when viewing data due to this reason (or a managed switch that can be set to mirror all ports).

Regards

Mark
Title: Re: uNetwork receive
Post by: intern on November 12, 2012, 11:22:43 AM
Thanks for all the time used on this problem..

With the new code uNetwork it worked.. 
I was working with a switch, but i thought it was a hub.. and with the new uNetwork there is no problem at all..