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.

2809 Problem with getting more ram to work in boot to saram

Hi,

I`m developing system using boot to saram, unfortunately there is a lack of free ram to fit my code into while debugging. I was hoping that if i change cmd file move dram do L1SARAM, and then i will have HOSARAM whole for my .text 8K (0x3FA000 - 0x3C000), but... when i moved DRAM like below i`m getting verification error ;/

MEMORY
{
PAGE 0 :
   /* For this example, H0 is split between PAGE 0 and PAGE 1 */ 
   /* BEGIN is used for the "boot to SARAM" bootloader mode   */
  
   BEGIN      : origin = 0x000000, length = 0x000002            
   RAMM0      : origin = 0x000002, length = 0x0003FE
   RAML0      : origin = 0x008000, length = 0x001000   
   PRAMH0     : origin = 0x3FA000, length = 0x002000
   RESET      : origin = 0x3FFFC0, length = 0x000002
   BOOTROM    : origin = 0x3FF000, length = 0x000FC0              

        
PAGE 1 :

   /* For this example, H0 is split between PAGE 0 and PAGE 1 */

   BOOT_RSVD   : origin = 0x000400, length = 0x000080     /* Part of M1, BOOT rom will use this for stack */
   RAMM1       : origin = 0x000480, length = 0x000380     /* on-chip RAM block M1 */
   DRAMH0   : origin = 0x3F9000, length = 0x001000        
}

 

Is there any chance to get more that 4K ram for debugging? Actually i`ve splitted program in few parts because the whole project will not fit into the ram. The can driver consumes about 6K, so to debug it i must have more that 4K. Any ideas? Maybe the problem is because te l0,l1 saram is secure zone, and h0 saram is not secured?

  • Hi,

    I have the same problem. My program is too large to fit into .text in "boot to saram" mode. And I can't access other memory locations such as 0x3F8000. Have you solved this problem or have you started programming with flash?

    Thanks in advance.

  • A couple of thoughts -

    L0, L1 and H0 are mirrored on the 2809 device.  That means the physical memory is accessed at two different locations (see the memory map in the data manual).  Make sure you haven't allocated data and/or code to both locations or it will get overwritten.  In general you will want to pick one or the other - the mirroring was done to allow for porting code from the 24x devices which most likely does not effect you.

    My other thought is that L0 and L1 are protected by the code security module (CSM).  At reset the CSM will lock.  If you have not programmed the password, you can easily  unlock it by simply doing a read of the password locations.  The easiest way to do this during debug is to open a memory window to the password at 0x3f7ff8-0x3f7fff.  CCS will refresh this window after a reset and thus unlock the device.

    -Lori

  • Thank you Lori.

    As I mentioned in my topic, I`ve suspected that there is maybe something wrong with the code security module. Reading that part of memory solved all problems!

    I hope that this topic will help a lot more 280x users whose are starting in texas hardware.

  • Yes, it solves the problem. Thank you.