uNetwork receive

[intern]

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.
 

[mark]

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

[intern]

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..

[intern]

Okay..
So now i have tried some time to get M52259DEMOkit to work.
The problem is not the uTasker 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.. 

[mark]

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

[intern]

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.

[mark]

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

[intern]

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.

[intern]

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??

[mark]

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

[intern]

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.

[mark]

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

[intern]

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..