Use of memset and memcpy

[sara2]

Posted on September 26, 2011 at 11:27

Hello,

I am using STM32-P103 to decode NMEA sentences with some codes that they were already written and making small changes in them and I have notice that the use of functions like memset and memcpy makes the system go into an infinite loop where it can't come out.

Is there a way to make it work with out getting it stuck there or an equivalent function to it?

I am using Eclipse and C++.

&sharpinclude <stdio.h>

&sharpinclude <stdlib.h>

&sharpinclude <string.h>

char* sixbit2bin(char* sixbit, int length)

{

    int i = 0;

    int value = 0;

    static char ret[MAX_RET];

    char tmp[10];

    memset(ret,0,sizeof(ret));

    if(length<=0)

        return NULL;

    for(i=0;i<length;i++)

    {

        value = sixbit[i]+40;

        if(value>128)

            value+= 32;

        else

            value+= 40;

        memset(tmp,0,sizeof(tmp));

        memcpy(&ret[6*i],&tmp[2],6);

    }

    ret[6*i] = '\0';

    return ret;

}

This is one of the functions in which it gets stuck...

Sorry if this is a stupid question but I can't find my way out of the problem. Thanksss

#fault-handler #fault-handler #fault-exception

[trevor23]

Posted on September 26, 2011 at 12:39

Hi,

To be able to help we need to see the code where sixbit2bin is used so we know how ''sixbit'' is allocated etc.. Also need to see where MAX_RET is defined. Can you add commecnts to the code also?

Regards

Trevor

[sara2]

Posted on September 26, 2011 at 14:40

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6aG&d=%2Fa%2F0X0000000brC%2FNQGT1f8WBb3gHOafB7Cl_6gqIYZDHWwj3Hr5LAMs7L8&asPdf=false

[Andrew Neil]

Posted on September 26, 2011 at 15:09

''an infinite loop where it can't come out''

 

Where, exactly, is that infinite loop?

Is it, perchance, in a Fault Handler?

 

 

If it is, then the status information will tell you what Fault occurred, and where

Google ''Cortex M3 Fault Handler''...

Also check your tool manuals for any help with this...

[Andrew Neil]

Posted on September 26, 2011 at 15:26

''Also check your tool manuals for any help with this''

 

eg,

http://www.keil.com/appnotes/files/apnt209.pdf

Not forgetting,of course,

http://infocentre.arm.com

[sara2]

Posted on September 26, 2011 at 15:48

Ill check them out but I dont think is that. When I say it gets into an infinite loop is because im putting nmea sentence constantly (every second) into the system and the only way I have to see that the mpu is working is with an oscilloscope, where I see the change in voltage.

In the code im sending out information through the USART2_TX so I can see when is sending data or not. And when I put some commands like memset or memcpy it seems that the systems gets into some kind of error or loop and doesnt react any more...same reaction when I write something wrong...like if a == 1 {} else if a == 1 instead of a != 1.

I hope this makes sense...

I will check the links anyway but I have a:

void hardfault_handler(void)

{

    return ;

}

Any idea what it could be?? Thanksss

[Andrew Neil]

Posted on September 26, 2011 at 18:07

''the only way I have to see that the mpu is working is with an oscilloscope''

Then get a JTAG probe - immediately!!

 

It is complete folly to even think of trying to develop without one!

If you really don't want to buy a separate JTAG probe, then get a Discovery board and develop your code on that. It has built-in JTAG, and only costs about $10.

[sara2]

Posted on September 26, 2011 at 18:14

I have the JTAG arm-usb-ocd and a STM32-P103...can I use these??

How?Sorry for my lack of knowledge... :$

[Tesla DeLorean]

Posted on September 26, 2011 at 19:12

This is the problem with the ''free'' route, the end-to-end integration of the development and debugging isn't there. Monetize your frustration. Consider some other chains, like Keil, IAR or Rowley, try the evaluations.

It's certainly possible to push debugging data out of the serial port, for that matter pushing diagnostics data from the hard fault handler out the serial port is also a viable path. That said, a JTAG debugger will save you a lot of time.

Joseph Yiu has published some code for the Hard Fault Handler, and it's been discussed/described here on the forum several times. The hard faults occur when you touch things improperly, or include ARM (32-bit) code into a Cortex-M3 project. Most examples just have a while(1); handler, which is pretty useless, at a minimum you want to know the instruction/address that is faulting and back propagate that into a map or listing file.

[infoinfo980]

Posted on September 26, 2011 at 21:25

The sixbit2bin function doesn't work.

''value'' is computed and never used.

''tmp'' is pointless as it appears to be a source of 6 zeros that could be got with a memset.

It's not re-entrant so calling it in main code and from an interrupt would be a disaster.

Overall it just zeros out some memory that's already zero, possibly with a buffer overrun.

[Andrew Neil]

Posted on September 27, 2011 at 08:10

''Sorry for my lack of knowledge.''

As you are already struggling due to lack of knowledg, the last thing you should be doing is diving into the arcane world of setting-up and configuring your own JTAG probe debugger!

You do not need the extra puzzles & pitfalls at this stage!

Get yourself a Discovery board, and use its built-in, ready-to-go JTAG probe to get your code working.

I believe that the built-in JTAG probe from the Discovery board can actually be used to debug other boards, but don't worry about that just yet - get the basics working

first

!