Author Topic: Newbie's firsttime with uTasker  (Read 55493 times)

Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #30 on: March 02, 2009, 01:50:51 AM »
Well I've tried everything and so far the only way I see this working is to call fnIKSClient() from application.c
How might I go about doing this properly since it's a task that needs to be executed.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #31 on: March 02, 2009, 01:45:31 PM »
Hi

Try adding a dummy call to fnIKSClient() from application.c, but somewhere where it is never actually called.

Eg:

int iDoCall = 0;  // global variable
...

if (iDoCall != 0) {
    fnIKSClient(0);
}


You have to trick the compiler/linker into not removing the call - the global variable will usually do it.

As you have already found, as long as fnIKSClient() is called form application.c its code is present and you can also debug in it. This should be enough to assure that.

The question is whether it is then scheduled correctly - eg. started after 200ms. This you will see when debugging. If it doesn't, it still means that it is not 'really' in your TaskConfig.h - which is the only logical explanation that I can think of, but why is beyond me.
If it does, it means that you have discovered a real problem with the GNU compiler since it is refusing to acknowledge the presence of your task code.

Make this last test and if the trick still doesn't work please zip your complete project (exactly as it is) and send it to me (Mark@uTasker.com). I will then open it exactly as you have it and attempt to explain what is happening.

Regards

Mark


Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #32 on: March 02, 2009, 08:47:52 PM »
Ok I've emailed my source code.
Just extract it into the application folder.

The trick worked to allow me to debug the code but my task was never called.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #33 on: March 02, 2009, 10:22:26 PM »
Hi

I am sorry but I have bad news.

I extracted the folder that you had compressed to the Applications\uTaskerV1.3 folder and then opened it in Rowely Crossworks.
Since the project didn't have paths to the debug code (since it was moved to another PC) I had to rebuild it.

Then I downloaded and set a break point in your task and it arrived there and I could step normally. See the screen shot below:

The only thing that didn't work as expected is that the task never exists. Instead it has optimised a loop away into a forever loop (which didn't occur in the simulator) so I am looking at why this should be the case (obviously something to do with the GCC optimiser).

My feeling is that when you compile the TaskConfig.h is still not being used correctly by the build because that's the only reason why the task's code would be missing in the debugger when not forced in by a dummy call and also why it wouldn't be scheduled.

I would try deleting the complete content of Applications\uTaskerV1.3\IKSClient\Rowley_LPC23XX\THUMB Flash Release so that it is impossible for something not be be compiled.
Also from Rowley try disassembling the individual file (Click on IKSClient.c in the project explorer - right click and Disassemble: I get three main disassemble block of lengths 0x82, 0x8e and 0x3e - does this correspond to what you see.
Then try the command "pre-process". It shows you all includes being used, the values inserted and will also show which code is being compiled and which not.

I will ask someone at Rowley to take a quick look to see whether there is an explanation for this. It is obvously not the code and not the Rowley project settings but rather something local to your PC, but this is the mystery which I just can't solve at the moment.

Regards

Mark

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #34 on: March 02, 2009, 10:29:40 PM »
Hi

Although not the real topic of the thread, the forever loop is due to a mismatch between the return value from fnReadIrd() and the length iSerialRxLenth

If static CHAR fnReadIrd(unsigned char * buf) is changed to static int fnReadIrd(unsigned char * buf) it is OK.

regards

Mark

Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #35 on: March 02, 2009, 11:29:45 PM »
Ok here's what I got when I disassemble
Code: [Select]
section .text

section .data

section .bss

section .text.fnSetNewSerialMode
  <fnSetNewSerialMode>:
  <fnIKSClient>:
   B570       push {r4-r6, lr}
   B084       sub sp, #0x010
   466D       mov r5, sp
   2301       movs r3, #0x01
   722B       strb r3, [r5, #0x08]
   4B1B       ldr r3, [pc, #0x06C]
   681A       ldr r2, [r3, #0x00]
   1C93       adds r3, r2, #0x2
   7FDB       ldrb r3, [r3, #0x1F]
   72EB       strb r3, [r5, #0x0B]
   2380       movs r3, #0x80
   015B       lsls r3, r3, #0x05
   80EB       strh r3, [r5, #0x06]
   2640       movs r6, #0x40
   2349       movs r3, #0x49
   732B       strb r3, [r5, #0x0C]
   80AE       strh r6, [r5, #0x04]
   1C13       adds r3, r2, #0x0
   334B       adds r3, #0x4B
   781B       ldrb r3, [r3, #0x00]
   736B       strb r3, [r5, #0x0D]
   1C13       adds r3, r2, #0x0
   334C       adds r3, #0x4C
   781B       ldrb r3, [r3, #0x00]
   73AB       strb r3, [r5, #0x0E]
   0601       lsls r1, r0, #0x18
   8B93       ldrh r3, [r2, #0x1C]
   0E09       lsrs r1, r1, #0x18
   2000       movs r0, #0x00
   466A       mov r2, sp
   802B       strh r3, [r5, #0x00]
   F7FFFFFE   bl 0x0000003E
   4C0E       ldr r4, [pc, #0x038]
   7020       strb r0, [r4, #0x00]
   2800       cmp r0, #0x00
   D010       beq 0x0000006C
   2105       movs r1, #0x05
   2200       movs r2, #0x00
   F7FFFFFE   bl 0x0000004E
   882B       ldrh r3, [r5, #0x00]
   4233       tst r3, r6
   D009       beq 0x0000006C
   4909       ldr r1, [pc, #0x024]
   2200       movs r2, #0x00
   7820       ldrb r0, [r4, #0x00]
   F7FFFFFE   bl 0x0000005E
   7820       ldrb r0, [r4, #0x00]
   2181       movs r1, #0x81
   2200       movs r2, #0x00
   F7FFFFFE   bl 0x00000068
   4B03       ldr r3, [pc, #0x00C]
   7818       ldrb r0, [r3, #0x00]
   B004       add sp, #0x010
   BC70       pop {r4-r6}
   BC02       pop {r1}
   4708       bx r1
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0404       lsls r4, r0, #0x10
   0000       lsls r0, r0, #0x00

section .text.fnIKSClient
  <fnSetNewSerialMode>:
  <fnIKSClient>:
   B510       push {r4, lr}
   4C1E       ldr r4, [pc, #0x078]
   7823       ldrb r3, [r4, #0x00]
   B081       sub sp, #0x004
   2B00       cmp r3, #0x00
   D125       bne 0x00000058
   2003       movs r0, #0x03
   F7FFFFFE   bl 0x0000000E
   7020       strb r0, [r4, #0x00]
   E020       b 0x00000058
   491A       ldr r1, [pc, #0x068]
   680A       ldr r2, [r1, #0x00]
   2A00       cmp r2, #0x00
   D107       bne 0x0000002E
   7822       ldrb r2, [r4, #0x00]
   2A21       cmp r2, #0x21
   D119       bne 0x00000058
   2301       movs r3, #0x01
   600B       str r3, [r1, #0x00]
   4B16       ldr r3, [pc, #0x058]
   701A       strb r2, [r3, #0x00]
   E014       b 0x00000058
   2A3F       cmp r2, #0x3F
   DD04       ble 0x0000003C
   4A15       ldr r2, [pc, #0x054]
   2300       movs r3, #0x00
   6013       str r3, [r2, #0x00]
   600B       str r3, [r1, #0x00]
   E00D       b 0x00000058
   7824       ldrb r4, [r4, #0x00]
   4B11       ldr r3, [pc, #0x044]
   1C50       adds r0, r2, #0x1
   54D4       strb r4, [r2, r3]
   6008       str r0, [r1, #0x00]
   2803       cmp r0, #0x03
   D102       bne 0x00000050
   4A0F       ldr r2, [pc, #0x03C]
   1CE3       adds r3, r4, #0x3
   6013       str r3, [r2, #0x00]
   4B0D       ldr r3, [pc, #0x034]
   681B       ldr r3, [r3, #0x00]
   4298       cmp r0, r3
   D00A       beq 0x0000006E
   4B08       ldr r3, [pc, #0x020]
   466C       mov r4, sp
   3403       adds r4, #0x03
   7818       ldrb r0, [r3, #0x00]
   1C21       adds r1, r4, #0x0
   2201       movs r2, #0x01
   F7FFFFFE   bl 0x00000064
   2800       cmp r0, #0x00
   D1D4       bne 0x00000016
   E001       b 0x00000072
   3001       adds r0, #0x01
   D1F2       bne 0x00000058
   B001       add sp, #0x004
   BC10       pop {r4}
   BC01       pop {r0}
   4700       bx r0
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00

section .bss.SerialPortID
  <fnSetNewSerialMode>:
  <fnIKSClient>:
   000C       lsls r4, r1, #0x00

section .bss.ucSerialInput.2174
  <fnSetNewSerialMode>:
  <fnIKSClient>:
   000C       lsls r4, r1, #0x00
   0000       lsls r0, r0, #0x00
   FFFFFFFF   undefined opcode
   0001       lsls r1, r0, #0x00
   7C01       ldrb r1, [r0, #0x10]
   0C0E       lsrs r6, r1, #0x10
   000D       lsls r5, r1, #0x00
   0024       lsls r4, r4, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0084       lsls r4, r0, #0x02
   0000       lsls r0, r0, #0x00
   0204       lsls r4, r0, #0x08
   0000       lsls r0, r0, #0x00
   0E00       lsrs r0, r0, #0x18
   8410       strh r0, [r2, #0x20]
   8504       strh r4, [r0, #0x28]
   8603       strh r3, [r0, #0x30]
   8E02       ldrh r2, [r0, #0x30]
   0401       lsls r1, r0, #0x10
   0002       lsls r2, r0, #0x00
   0000       lsls r0, r0, #0x00
   200E       movs r0, #0x0E
   0000       lsls r0, r0, #0x00
   0020       lsls r0, r4, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00
   0000       lsls r0, r0, #0x00

section .bss.iExpectedbytes.2153
  <fnSetNewSerialMode>:
  <fnIKSClient>:
   000C       lsls r4, r1, #0x00
   0000       lsls r0, r0, #0x00

section .bss.iRxReceived.2152
  <fnSetNewSerialMode>:
  <fnIKSClient>:
   000C       lsls r4, r1, #0x00
   0000       lsls r0, r0, #0x00

Still I'm unable to set breakpoints

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #36 on: March 03, 2009, 12:30:22 AM »
Hi

This is identical to mine. Compiling is good.

I have sent you the map file (per email) generated when I build. Perhaps you can see a difference in the content.

I have asked Rowley to take a look. At the moment I am out of ideas apart from to try working in a different PC to see whether there is a change.

Regards

Mark


Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #37 on: March 03, 2009, 01:06:07 AM »
ok I've gone as far as to install crossworks on my laptop and try it there and it was a no go.
i'm starting to wonder if it's my utasker source ?

Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #38 on: March 03, 2009, 01:16:01 AM »
Ok I got it to work but the way I did it is completly messed up.
I re-extracted the utasker along with service pack 3 and instead of copying the folder to a new folder to start a new project I just decided to edit it as is.

It worked!!!

So then I re-opened my older IKS project we've been messing with and it works now as well.

Why is this ?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #39 on: March 03, 2009, 02:37:40 AM »
Hi

I am pleased that it has started to work but can't explain what was going on.
That the project which was not working also suddenly started is a further mystery. [Perhaps someone else can think of an explanation]

I hope that it at least continues working from now.

And, that you can finally start doing some real work - hopefully you can make up some lost time using the features in the project...

Also don't forget to try the uTasker simulator since this can save most real development time and also avoids a lot of work on the target.

Regards

Mark


Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #40 on: March 03, 2009, 03:05:52 AM »
Let me explain what I did.

I extracted a fresh copy of utasker and utasker sp3

I then opened up taskconfig.h inside of the utaskerv1.3 folder and added in my iksclient task and then I also created a new file called iksclient.c and added in my own code.

I then debugged/compiled and it worked perfectly.

So after doing so I reloaded my old project located under folder iksclient and it started working as well.

So for some reason the changed I made to file TaskConfig.h in folder utaskerv1.3 reflected on what I was compiling in folder iksclient which should have been a seperate project folder all together with it's own taskconfig.h file but it would appear that when modifying taskconfig.h contained under iksclient folder it would do simply nothing.

any reason for this ? perchance it's a path or file setup incorrectly in utasker ?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #41 on: March 03, 2009, 03:24:07 AM »
Hi

Each application folder contains its own:
- config.h
- TaskConfig.h
- Types.h and
- app_hw_xxxx.h

In Rowley Crossworks there is a setting: Preprocessor Options -> User Include Directories
This path is set to ..\\..\\..\\Applications\\uTaskerV1.3 in the demo project.

When a new project folder is created but this include path not modified to suit, it is probable that some files will be using includes from the demo project. I expect this is the problem that you had. In fact, I don't think that the project corrected itself but rather you had compiled a configuration using a modified TaskConfig.h in the demo which is then being used for the new project setting too.

If even in doubt about which includes are being used, it is always a good idea to intentionally add an error to the file and recompile. If the build works it means that the compiler didn't see the error and is therefore working with a different file!

Therefore I think that this now does explain the problem. I didn't see it because I replaced the uTaskerV1.3 content in my tests with your code since I didn't realise that you had copied the project directory.

I will rework the "uTasker - First Steps for new Users" document so that this point is made clear to avoid similar difficulties.

regards

Mark






Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #42 on: March 03, 2009, 03:39:09 AM »
Now with that being finally solved and outta the way I seem to have some issue with my code.

In function fnReadIRD() where it says "if (ucInputMessage != 0x21) {" it never seems to equal 0x21

Now the device that sends the data to my ARM7 via uart1 has all it's packets start with 21 so I'm lost why it's not working with uTasker but the same code in the past has worked with other tasking projects ...

Any idea's ?

Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #43 on: March 03, 2009, 04:13:28 AM »
Ok by running the simulator I'm finding the first value it gets is "33" which is the DEC equiv to "21" in hex.
Why would it be in DEC and not in HEX ? Is this something to do with fnRead ?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #44 on: March 03, 2009, 01:32:04 PM »
Hi

fnRead() doesn't change content in any way.

Check that your settings for the interface speed, parity etc. match correctly.
Also try by sending to a normal terminal emulator to see the data that is being received - 0x21 is '!' and so is visible. 0x33 is '3' - so you can verify.

If you are saying that it is displaying 33 dec, this is identical to 0x21 hex (the debugger can be set to display hex or dec) so would in fact be correct.

I just simulated your code and sent 0x21 (33) by typing in '!' from a terminal emulator connected to the UART. The task was woken and the receiver synchronised (0x21 or 33 was put to buf[0]):

      if (iRxReceived == 0) {                                            // searching for sync byte
          if (ucInputMessage != 0x21) {
              continue;                                                  // still not found sync byte
          }
          iRxReceived = 1;                                               // synchronised
          buf[0] = ucInputMessage;


Therefore it looks to be good.
Please check again - I am sure that there are no problems with the UARTs but more a misunderstanding somewhere.

Regards

Mark