This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

F28335: Exactly the same code give different results, Ubuntu vs DSP

I have made an implementation in C++ on an Ubuntu system (Intel processor) using the gcc compiler. Now I ran exactly the same code on the F28335 and got another result. Only a third of the returned signal values (every third index) seem the same.

Any thoughts on what may have happened? I've had some memory issues with a too small stack, but it executes and returns so it should be ok. Do big/small endian make a difference?

Below is my memory configuration, in case there is a problem with that.

 

MEMORY

{

PAGE 0 :

   /* BEGIN is used for the "boot to SARAM" bootloader mode      */

   BEGIN      : origin = 0x000000, length = 0x000002     /* Boot to M0 will go here                      */

   RAMM0      : origin = 0x000050, length = 0x0003B0

   RAML0      : origin = 0x008000, length = 0x0039D0

   RAML1      : origin = 0x00B9D0, length = 0x000040

   RAML2      : origin = 0x00BA10, length = 0x000040

   RAML3      : origin = 0x00BA50, length = 0x000040

   ZONE7A     : origin = 0x200000, length = 0x00FC00    /* XINTF zone 7 - program space */

   CSM_RSVD   : origin = 0x33FF80, length = 0x000076     /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */

   CSM_PWL    : origin = 0x33FFF8, length = 0x000008     /* Part of FLASHA.  CSM password locations in FLASHA            */

   ADC_CAL    : origin = 0x380080, length = 0x000009

   RESET      : origin = 0x3FFFC0, length = 0x000002

   IQTABLES   : origin = 0x3FE000, length = 0x000b50

   IQTABLES2  : origin = 0x3FEB50, length = 0x00008c

   FPUTABLES  : origin = 0x3FEBDC, length = 0x0006A0

   BOOTROM    : origin = 0x3FF27C, length = 0x000D44

 

PAGE 1 :

   /* BOOT_RSVD is used by the boot ROM for stack.               */

   /* This section is only reserved to keep the BOOT ROM from    */

   /* corrupting this area during the debug process              */

   BOOT_RSVD  : origin = 0x000002, length = 0x00004E     /* Part of M0, BOOT rom will use this for stack */

   RAMM1      : origin = 0x000400, length = 0x000480     /* on-chip RAM block M1 */

   RAML4      : origin = 0x00BA90, length = 0x000040

   RAML5      : origin = 0x00BAD0, length = 0x0040F0

   RAML6      : origin = 0x00FBC0, length = 0x000400

   RAML7      : origin = 0x00FFC0, length = 0x000040

   ZONE7B     : origin = 0x20FC00, length = 0x000400     /* XINTF zone 7 - data space */

}

 

SECTIONS

{

   /* Setup for "boot to SARAM" mode:

      The codestart section (found in DSP28_CodeStartBranch.asm)

      re-directs execution to the start of user code.  */

   codestart        : > BEGIN,     PAGE = 0

   ramfuncs         : > RAML0,     PAGE = 0

   .text            : > RAML0,     PAGE = 0

   .cinit           : > RAML0,     PAGE = 0

   .pinit           : > RAML0,     PAGE = 0

   .switch          : > RAML0,     PAGE = 0

   .stack           : > RAML5,     PAGE = 1

   .ebss            : > RAMM1,     PAGE = 1

   .econst          : > RAML6,     PAGE = 1

   .esysmem         : > RAMM1,     PAGE = 1

   .cio : > RAMM0,    PAGE = 0

  • What type of code you are running.. is it an algorithm to compute something ?

    Did you type casted every variable to explicitly tell to the compiler how to handle every variable ?

    If not, this can lead to problems because type are not the same on every architecture.

  • I found the problem. It was about types on different platforms. On the Ubuntu I had 4 byte ints, on the F28335 there is only 2 byte ints. What happens is that high values will be strange when the unsigned ints is only 0 - 65535.