Debug problem

[rad]

Hi All,

I use CW6.4 with 52233DEMO, and When I set a breakpoint in any file and try debug uTasker v.1.3, it stops at the breakpoint correctly for the first time, but when I try to start project again, It will say that project is running, but it doesnt work (wdt LED not blink and I cannot ping at the board) and of course it will not stop at the breakpoint anymore. When I kill debug session, CW says that apps is still running, but as I said de facto it isnt true. If I start the debug session again, it works well for the first time again, but just for the first stop. I tried to change optimize for lower level but it doesnt help.

Also when I add a file myTask with fnMyTask at the project and try to debug it in the simulator, VS says there are missing _fnMyTask. I dont know where I have to add it. If I add some macros or consts, I can manage to correct errors (missing macros or consts), but not with new functions. Maybe I used wrong way to add the file in the proj...I create empty file myTask.c and then add it in the project. Next step I create function and write some code there. Funny is, that in CW and 52335DEMO it works well (but with debug problems I described above). Anyone have a idea or solution?

Rad

[mark]

Hi Rad

It is not possible to debug when the watchdog is active - when the debug break is hit, the watchdog then times out and doesn't allow the debugger to continue working correctly. There are 2 methods to get around this:
1. Compile the project with disabled watchdog
2. Connect the IRQ4 to GND to disable temporarily

This is described also in the tutorial page 14/34.

Afterwards you should find that debugging works well.

I don't know why the VS project has a problem with your new task but it does seem as though it is not using your new file. Ensure that the file is not set to be excluded from the project (somewhere in compiler setting for file).
For a quick solution to the problem, copy the file content to an existing file (eg. to the end of application.c) and this will certainly be included!

Regards

Mark

[rad]

Hi Mark,

thank You for Your really fast reply, My idea about watchdog was, it is just "dummy" for blink the led..:-) So I try to disable it and will see (in point 1, You probably mean compile project with disabled watchdog, not interrupt. I expect, that disable interrupt will not sort it out..:-)). Anyway, If I disable it (no matter how) it will not blink led, because wdt timer will stop, Im right?

According watchdog behavior, if it fired,  CPU is hw reset into init state or its something like sw reset? Because it look like cpu stay freezed (no blink leds, no response at ping or others ext. events). When I reset the board with reset button, it start works correctly.

I also try to move My func into application.c and try VS if it works correctly. I had an idea, that it tries to make windows version of MyTask (because my function has name fnMyTask() and compiler says there is missing _fnMyTask(), underline before name of func is usually used for windows version). Maybe I put MyTask file into wrong directory...

Thanks and have a nice day, Rad

[mark]

Rad

Yes, that was a mistake with "interrupt" - I have corrected it to "watchdog".

To disable the watchdog (not activate it) change the following define in app_hw_m5223x.h:
#define CONFIGURE_WATCHDOG         ACTIVE_WATCHDOG_2_SEC
to
#define CONFIGURE_WATCHDOG         0

This will then still toggle the watchdog LED (useful to see that the board is correctly functioning) but the watchdog is not configured to actually operate, so it will not timeout when debugging.

The watchdog in the M5223X can't actually generate a reset but instead only an interrupt. This interrupt routien (given NMI priority in the project) actively commands the HW reset.

Regards

Mark

[rad]

Hi Mark,

thank You for Your help again, now its all working, even Win Simulator. I changed My func into application.c and it works..(I had to comment out #define OWN_TASK   MY_FIRST_TASK, it was probably biggest problem with simulator). Anyway, when I disable watchdog, I had to change #define CONFIGURE_WATCHDOG    0, because without zero compiler says an error (I found out in the datasheet, that I have to clear bit in CWR, which actually is done after reset).

I get to know with utasker, and it looks really nice... but I will have some more questions..first, can I still use my own interrupt routines? Or do You have any better sugestion? For example I need to detect press two buttons (let say In and Out). When I press one of them, some status will change and a 5sec. (or so) period will start. In this period second has to be action entered (some input from serial port). If this period overflow without second action, status will change back to 0. If I press second button during this period, status will change to another state (so in this example, I expect three state indicator- zero as nothing to do, 1 as In button pressed and 2 as Out button pressed). So My func will be wake up when button is pressed (interrupt routine will wake up my func with status I described) and if 5sec timer overflow with no serial port input, my func will sleep again with status cleared. If I press another button, my func has to get new status with new timer interval (replace old one) and wait for serial input again. If serial input is done, it will save event, clear timer and sleep again.

Another question- If I want simply connect (buffered TCP/IP), I expect to create connection with function call listen(); or connect(); with IP adress and port like args (I dont know the right names of the function in Your system, but it doesnt matter now, I will find it later). Then I will let My task sleep till "connected event" wake up my task again and I will sort out right event (succesfully connected, connection failed, or so). If its connected, I can send any data by another function datasend(); or datareceived(); (with pointer to data buffer). Is this method right? Or miss I something? Also, will My task sleep till data is sent or received (I expect utasker will wake up it with event data sent or received)? Or have I polling this events? Especially with data received, It will inform Me about every packet received, or just when buffer is full? Maybe My questions are a bit stupid, but I didnt work with utasker (nor with any embedded OS) before..

Anyway, thank You again for Your good job, I dont know about utasker much yet, but I see it will be great get to know it and use it...It must really save time..

Regards, Rad

[mark]

Hi Rad

My mistake: I have corrected the disabled watchdog value of 0 in my post.

>>can I still use my own interrupt routines?
You are free to use your own interrupt routines - interrupts have nothing to do with the OS so can be either considered as independent, but they can also be used to schedule things (eg. see the use of fnInterruptMessage() in some other interupts which is used to wake a specific task with an event).

>>For example I need to detect press two buttons...
To do this you can quite easily use the uTasker support as follows:
1. Configure the edge port interrupt on the corresponding edges - see fnInitIRQ() in application.c for an example.
For each input you define an interrupt handler, say key1() and key2().

2. When the first key is pressed you can change a state variable (and possible LED indication) in the handler key1(). You can also start a timer (eg. uTaskerMonoTimer( OWN_TASK, (DELAY_LIMIT)(5*SEC), E_KEY_TIMEOUT ); When the timeout arrives you can reset the state variable.

3. When the second key is pressed it is handled in key2(). Depending on the state it can perform the desired action.

>>I expect to create connection with function call listen(); or connect(); with IP adress and port like args...
You should find all information relevant to using TCP (and buffered TCP) in the following thread: http://www.utasker.com/forum/index.php?topic=25.0

When working with a TCP socket it doesn't need a task of its own since it always works with a call-back function (listener) which will be called by the TCP/IP stack to handle events. Often all processing for the connection can be performed in this call-back.
However the call back can also work together with a task - it can wake the task or send events or messages to it when certain events occur. A task can also send data to the socket.

There is never any need to poll when working with the Ethernet interface - it is completely event driven. The Ethernet connection is frame oriented so the listener will receive an event for each frame received; the data length being equal to the received frame length.


Regards

Mark