Author Topic: strtok  (Read 4023 times)

Offline Phil

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
strtok
« on: February 06, 2019, 12:09:24 AM »
Mark,

Had something happen today that was rather strange.

I was reusing some code developed on a K64 and using this with a KL27. Interestingly, I ran into a bunch of problems related to the handling of strings. Simple things like defining an array of characters predefined to a 0 or using a strtok string function.  I know we had issues with strcpy and these types of functions but are these issues related?

Finest regards,

Phil

Offline Phil

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Re: strtok
« Reply #1 on: February 06, 2019, 12:12:14 AM »
Snipet of code in question:

void fnDoSwitch(unsigned char ucType, char *ptrInput)
{
   char *arg1;
   char buff[64];
   int i = -1;

   uStrcpy(buff,ptrInput);

   arg1 = strtok(buff, " \r");
...

Offline Phil

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Re: strtok
« Reply #2 on: February 06, 2019, 12:17:50 AM »
Attached is the debug trail that shows the hard fault originated from the strtok string parse function.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: strtok
« Reply #3 on: February 06, 2019, 02:54:00 AM »
Hi Phil

It sounds to me as though you are using a library for a Cortex-M4 on a Cortex-M0+, which will fail due to it using instructions that the Cortex-M0+ doesn't support.

Therefore check which library is being used (for the strtok()) and adjust it (or rebuild it) for the target in question.

Good luck

Regards

Mark

Offline Phil

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Re: strtok
« Reply #4 on: February 06, 2019, 06:33:25 PM »
Thanks, Mark.

I would think that changing the "Target Processor" in the C Build settings would point to the correct standard libraries.

Regards,

Phil

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: strtok
« Reply #5 on: February 07, 2019, 01:59:32 PM »
Phil

Yes I would expect this too but it is the only explanation that I have.

From your call stack everything is OK before you enter the strtok() so the best thing to do is to set a break point on this line and then step into it in disassembler mode (maybe you can also find source level debugging capability on the library) - they you need to step until it fails and see what instruction it is or whether it is due to a bad memory access. If you can identify an instruction failing look it up in the Cortex-M0+ instruction set to see whether it exists. If it doesn't but does exist in the M4 set it will be the wrong library.
Note that if it a library target issue it won't normally take a lot of stepping to find it.

Regards

Mark