• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 56 subscribers
  • Views 999 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Z-stack example application generates hex file larger than 128 kb

Therese
Prodigy 40 points
Other Parts Discussed in Thread: CC2431, Z-STACK, CC2430

Hi all!

I am using IAR EW v7.50 to compile TI's Z-stack examples to use with a CC2431. When I compile the location sample app and generate a hex file, the hex file gets a size of 256 kb. Since the processors flash is limited to 128 kb and since the samples are aimed at this device the logical thing would be to think that something is wrong with my settings or compile options. Thus, I am wondering if someone else has had any experience of this problem and how they, hopefully, resolved it.

The -M option in the linker file is being used if that helps clarify anything.

Happy for answers and clues!

Best Regards

Therese

  • 0
    TI__Mastermind 19350 points

    The Intel extended hex file format is ascii so that it can be easily human readable - since it takes 2 ascii characters to represent one code byte, that alone doubles the size. Furthermore, the file format contains header, footer, and addressing information which makes it bigger still than the actual code size of the code it contains. Open the folder named 'Output' and open the file with the '.map' suffix and scroll to the end of it to see the actual code size (the sum of the CODE and the DATA sizes) which will look something like this:


                    ****************************************
                    *                                      *
                    *        END OF CROSS REFERENCE        *
                    *                                      *
                    ****************************************

     114 571 bytes of CODE  memory
          19 bytes of DATA  memory (+ 80 absolute )
       4 995 bytes of XDATA memory
         192 bytes of IDATA memory
           8 bits  of BIT   memory
         390 bytes of CONST memory

    Errors: none
    Warnings: none

     

  • 0 in reply to Dirty Harry
    Prodigy 40 points

    Thank you for your answer.

    However, when you want to program your device using SmartRF Flash Programmer, it complains about the size of the hex, which it finds too large. Sure, I can use IAR to load the device with the application, but maybe there is a solution so that the Flash Programmer could be used as well.

    //Therese

  • 0 in reply to Therese
    TI__Mastermind 19350 points

    The CC2430 was last supported with Z-Stack 1.4.3 which used the IAR V7.30B. This means that libraries are compiled with V7.30B and are probably not compatible with application code compiled with later versions of IAR. There are a lot of threads about this, just search for '1.4.3 IAR'

  • 0 in reply to Dirty Harry
    Intellectual 570 points

    Hi Harry,

    I have a old SmartRF04EB kit, the CC2430 IC hardware version is " CHVER = 0x01", I download CC2430_Software_Examples and TIMAC-CC2430-1.3.0 recently, compile with IAR EW8051 V7.51A,  download to the CC2430EM in the SmartRF04EB, but it seems don't work as expected. I'm not sure it is causing by old CC2430 IC or something wrong with compiler settings.

    In the CC2430_Software_Examples, the problem is "light_Switch-srf04_CC2430" doesn't send RF signal, but "Per_Test-srf04_cc2430" send RF signal. 

    uint8 halRfTransmit(void)
    {
        uint8 status;

        ISTXON(); // Sending   === >Single debug here don't send RF signal.

        // Waiting for transmission to finish
        while(!(RFIF & IRQ_TXDONE) );

        RFIF = ~IRQ_TXDONE;
        status= SUCCESS;

        return status;
    }

    In the TIMAC-CC2430-1.3.0, the software hangs up at MAC_Init().

    int main(void)
    {
      /* Initialize hardware */
      HAL_BOARD_INIT();

      /* Initialze the HAL driver */
      HalDriverInit();

      /* Initialize MAC */
      MAC_Init();      //Hangs here

      /* Initialize the operating system */
      osal_init_system();

    ...............

    }

    Any suggestions? Looking forward to your reply.

    Samuel

     

     

  • 0 in reply to samuel zhang
    TI__Mastermind 19350 points

    My suggestion is to throw away that defunct H/W - version 0x01 ... belongs in a museum or trash. Take a look at this comment in code that you have access to, mac_mcu.c:

      MAC_ASSERT(CHVER >= 0x03); /* chip versions before version D are obsolete */