Чтение бинарного файла в проэкт TI C5402, Происходит бардак - помогите разобраться... Опции

[Саша Z]

Вроде элементарная вещь - читаю бинарный файл в память C5402, элементарный код, а виснет ...
Код:

Код

#include <stdio.h>
#include <stdlib.h>


void f_write(char *str,int arr[],int N);
void f_read(char *str,int arr[],int N);

int z1[1000],Nfloat;

void main()
{ int i;

char str1[]="C:\\Ti\\myprojects\\Project\\Project\\zoom_inst1";
char str2[]="C:\\Ti\\myprojects\\Project\\Project\\zoom_inst1_out";


for (i=0;i<1000;i++)
    z1[i]=0;

puts("start");
f_read(str1,z1,1000);

f_write(str2,z1,1000);
puts("end");
}
            
void f_read(char *str,int arr[],int N )    
{
      FILE  *fr;
      fr = fopen(str,"rb");
      fseek(fr, 0, 0);                          
      fread(arr,1,N,fr);
      fclose(fr);
}
void f_write(char *str,int arr[],int N)  
{
    FILE  *fw;
    fw = fopen(str, "wb");
    fwrite(arr,1,N,fw);
    fclose(fw);
}

Бинарный файл содержит 5800 последовательных байт (2900 integres), в коде проведенном выше - читаю первых 1000 байт а массив z1 (массив заявлен как integer).
На данный момент работаю на симуятор C5402 (т.е. без подключенного борта).
В таком состоянии (чтение 1000 байт) - вроде работает нормально, данные читаются в массив z1.

Задача - прочесть все 5800 байт из исходного файла. Проблема возникает когда увеличиваю размеры массива и чтения файла - скажем говорю прочитать 2000 байт (измению 1000 на 2000 везде где надо в сорсе) - тут программа виснет где-то в процессе чтения файла. Не пойму что происходит...

Конфигурация памяти очень проста:

Код

MEMORY
{
    PAGE 0: EPROG: origin = 0x1200, len = 0x7c00
          
    PAGE 1: IDATA: origin = 0x80,   len =0x8000
}  

SECTIONS
{
  
    .text:    {} > EPROG PAGE 0
    .bss:     {} > IDATA PAGE 1
    .const:   {} > IDATA PAGE 1
    .switch:  {} > IDATA PAGE 1
    .sysmem:  {} > IDATA PAGE 1
    .stack    {} > IDATA PAGE 1
}

думал проблема может быть в памяти - но вроде ее достаточно в конфигурации.

Подскажите что может быть ?

Спасибо

[BratherLU]

1 - Внимательно посмотрите datasheet на tms5402 а именно раздел Memory Map
В Том диапазоне адресов, что Вы указали для EPROG и DATA в .cmd файле у 5402
есть непрерывный участок размером только 0x4000 слов, как для программной памяти так и для памяти данных
Полный объем внутреенней оперативной памяти для с5402 (16 кСлов = 0x4000))

Так что если симулятор стерпел, то при загрузке в реальную железку CCS скорее всего изругается :)

2 - если в регистре pmst MP/MC=0 и OVLY=1 то диапазон 0x0000 0x4000 Это Физичиски Одна и Таже Оперативная Память

[Саша Z]

1 - Внимательно посмотрите datasheet на tms5402 а именно раздел Memory Map
В Том диапазоне адресов, что Вы указали для EPROG и DATA в .cmd файле у 5402
есть непрерывный участок размером только 0x4000 слов, как для программной памяти так и для памяти данных
Полный объем внутреенней оперативной памяти для с5402 (16 кСлов = 0x4000))

Так что если симулятор стерпел, то при загрузке в реальную железку CCS скорее всего изругается

2 - если в регистре pmst MP/MC=0 и OVLY=1 то диапазон 0x0000 0x4000 Это Физичиски Одна и Таже Оперативная Память

Спасибо за ответ, на вас можно положиться...

Да, cmd файл я взял общего плана, он не тюненный конкретно под аппликацию.
Сейчас его подкорректировал под конкретные объемы кода (согласно map файлу):

Код

MEMORY CONFIGURATION

                  name            origin    length      used    attr    fill
         ----------------------  --------  ---------  --------  ----  --------
PAGE  0: EPROG                   00000080   00001200  0000106b  RWIX

PAGE  1: IDATA                   00001200   00004000  00002527  RWIX

Согласно этому и желая все вместить во внутреннюю память процессора (она ка вы и сказали от 0х80 до 0х4000 т.е. около 16 kwords), я дал следущую конфигурацию:

Код

MEMORY
{
    PAGE 0: EPROG: origin = 0x80, len = 0x1200
          
    PAGE 1: IDATA: origin = 0x1280,   len =0x2D80
}  

SECTIONS
{
  
    .text:    {} > EPROG PAGE 0
    .bss:     {} > IDATA PAGE 1
    .const:   {} > IDATA PAGE 1
    .switch:  {} > IDATA PAGE 1
    .sysmem:  {} > IDATA PAGE 1
    .stack    {} > IDATA PAGE 1
}

В сумме получается от 0х80 до 0х4000, т.е. влазит вроде во внутреннюю память процессора, но довольно-таки впритык (согласно map файлу, используется под код и данные в сумме в районе 14kB из чуть менее 16 kB всего внутренней).

В симуляторе работает на полный файл данных (5800 байт), подключил на борд - пока тоже работает, вроде стабильно. Вопрос будет ли и дальше стабильно работать...

Возникает проблема теперь с дальнейшим расширением программы. Подразумеватеся обработки данных, значит и код и данные увеличаться, наверняка внутренней памяти не хватит. На борту есть внешний SRAM который по идее расширяет системную память до 64 kB (максимум данного процессора в обычном режиме работы). Видимо придется разбиратся как кнофигурировать програмно работу с внешней и внутренней памятью (думаю загружать массивы данных во внешнюю, затем подкачивать по частямво внутреннюю для обработки...)...пока для меня это все ново...

Одним словом Вы скорее всего затираете часть кода во время записи данных в Ваши Массивы

ООоо, вот это новая инфа к размышлению для меня...
Т.е. вы имеете ввиду то что вследствие частичного перекрытия оговоренных в cmd файле зон памяти между кодом и данными, часть данных пишутся в кодовую зону затирая часть кода ?
Я принципе я могу это понять, но я всегда считал что линкер сам позаботиться о физическом разделении
зон кода и данных, даже ежели они частично перекрываются в заданной конфигурации памяти....
Я ошибаюсь ?