TMS320F28335 - формирование .bin файла для записи из внутри, Нужно записать прошивку не через CCS, а через FlashAPI Опции

[PrSt]

Есть уже мной написанный загрузчик через CAN(пропустим особенности, они не нежны). Он получает прошивку, которую помещает в ОЗУ. От туда её нужно записать в DSP Flash чтоб потом нормально с неё загружаться.
То есть, мне нужно записать прошивку, не через CCS, а через внтруннюю FlashAPI, своей программой.У меня TMS320F28335 - как устроено формирование .bin файла я разобрался,
но не могу понять как сделать формирование этой прошивки в .bin для записи из ОЗУ внутри.
Когда я получаю прошивку через CAN и записываю +передергиваю питание... она не стартует, а если ту же прошивку записать через CCS, то все работает. кстати если сразу после прошивки начать дебажить, то она работает. Также я проверил содержимое флэша, по тем адресам, что в бинарике, они так же там же находятся в флеше после записи, то есть полностью правильно записываются.
Такая же задача, но с записью в OTP секцию - работает, а вот с записью в флэш - не получается..., возможно что то с линкер файлом.
Помогите плиз разобраться с проблемой, а то уже мозги выкручиваются...

[doom13]

Ответте, пожалуйста на следующие вопросы:
1. Какой режим загрузки процессора выбран железно пинами (он не меняется!!!) и, соответственно, с каких адресов стартует процессор при включении питания?
2. Что делает OTP загрузчик после загрузки загрузчика второго уровня в RAM? Каждый ли раз при включении питания происходит загрузка загрузчика второго уровня в RAM?
3. Что делает загрузчик второго уровня после записи прошивки во флэш-память? Каждый ли раз при включении питания происходит загрузка прошивки и её запись во флэш?

Щас вопрос не про загрузку. Там я уже разобрался давно. Тут вопрос про то если этот код загружен уже в ОЗУ и из него произвидится запись в флеш, тоесть мне прилетает стрим и я его должен записать, потом перегрузиться и должно работать с новой прошивкой.

Тут и нужно понимать алгоритм запуска, всю последовательность передачи управления (из Вашего описания не совсем понятно), иначе ничего не должно работать, вобщем ответте на вопросы, а там дальше посмотрим.

на данном этапе, в вопросе это по идее и не важно, исходим из того что программа уже в работе...

Программа в работе, если процессор перешёл на адрес выполнения программы, тут-то у Вас, по-идее, и проблема.

Да все стандартно, линкуются секции
codestart .initboot .text cinit, .pinit ... итд.
юзается библиотека rts2800_ml.lib которая предоставляет точку входа _c_int00 и она уже вызывает main()
Классика.

Классика, это когда выбран режим загрузки с флэша, вы кладёте прошивку по нужным адресам флэша и при включении питания она стартует. У Вас же несколько этапов загрузки, так что рассказывайте всё по-порядку.

[PrSt]

Ответте, пожалуйста на следующие вопросы:

1. Какой режим загрузки процессора выбран железно пинами (он не меняется!!!) и, соответственно, с каких адресов стартует процессор при включении питания?

у меня на плате по дефолту предполагается загрузка только в отп режиме. но так как щас еще не все части работают то я их вынужден проверять либо с флэша, либо с озу.

2. Что делает OTP загрузчик после загрузки загрузчика второго уровня в RAM? Каждый ли раз при включении питания происходит загрузка загрузчика второго уровня в RAM?

-переходит на адрес старта 2го уровня, который в свою очередь скачивает прошивку большого размера. это происходит не каждый раз, а только когда найден установленный флаг, иначе переходит на адрес выполнения старой программы и не обновляет.

3. Что делает загрузчик второго уровня после записи прошивки во флэш-память? Каждый ли раз при включении питания происходит загрузка прошивки и её запись во флэш?

Тут и нужно понимать алгоритм запуска, всю последовательность передачи управления (из Вашего описания не совсем понятно), иначе ничего не должно работать, вобщем ответте на вопросы, а там дальше посмотрим.

выше я уже написал что загрузка 2го не всегда, а только при наличии явного указания для обновления.

Программа в работе, если процессор перешёл на адрес выполнения программы, тут-то у Вас, по-идее, и проблема.


Классика, это когда выбран режим загрузки с флэша, вы кладёте прошивку по нужным адресам флэша и при включении питания она стартует. У Вас же несколько этапов загрузки, так что рассказывайте всё по-порядку.

у меня отп режим который при старте смотрит нужноли скачивать новую прошивку, если не нужно, старт старой. если нужно то качается 2го уровня, запускается, скачивается полностью фирмваря и записывается вместо старой.

[doom13]

И так, Ваш алгоритм старта процессора: (рисунок).

1. На плате железно выбран режим Boot To OTP.
2. Проверяем ветку, где не требуется загрузка новой прошивки.

В ОТР прошит загрузчик, который должен стартануть основную программу. Основную программу заливаем при помощи CCS, ставим точку останова в начале main, из ССS делаем Reset, далее Run, процессор должен прийти на нашу точку останова. Если нет, разбираемся, что по каким адресам положили и почему ОТР загрузчик не стартует основную программу во флэш-памяти

3. Проверяем работу второй ветки аналогичным способом.

Если уверены, что программа записывается правильно загрузчиком второго уровня, то заливаем её из CCS, ставим точку останова в начале main, из ССS делаем Reset, далее Run, и посылаем процессору загрузчик второго уровня и эту же прошивку, после перепрошивки флэша процессор должен попасть на нашу точку останова. Если нет, но уверены что во флэш легло всё правильно, то смотрим как передаётся управление загрузчиком второго уровня из RAM.

Эскизы прикрепленных изображений

 

[PrSt]

И так, Ваш алгоритм старта процессора: (рисунок).
1. На плате железно выбран режим Boot To OTP.
2. Проверяем ветку, где не требуется загрузка новой прошивки.

В ОТР прошит загрузчик, который должен стартануть основную программу. Основную программу заливаем при помощи CCS, ставим точку останова в начале main, из ССS делаем Reset, далее Run, процессор должен прийти на нашу точку останова. Если нет, разбираемся, что по каким адресам положили и почему ОТР загрузчик не стартует основную программу во флэш-памяти

о, вот комбинировано я еще не пробовал, все время симуллировал, то в флеше, то в озу. Спасибо за совет.

3. Проверяем работу второй ветки аналогичным способом.

Если уверены, что программа записывается правильно загрузчиком второго уровня, то заливаем её из CCS, ставим точку останова в начале main, из ССS делаем Reset, далее Run, и посылаем процессору загрузчик второго уровня и эту же прошивку, после перепрошивки флэша процессор должен попасть на нашу точку останова. Если нет, но уверены что во флэш легло всё правильно, то смотрим как передаётся управление загрузчиком второго уровня из RAM.

Да именно так и делаю, сегодня как раз дебажил (но еще не до конца). Все так, только за одним исключением, я прыгаю не на 0033fff6, а на EntryPoint, который мне сообщается в бинарике.

Подскажите тогда сразу по ходу и на другие вопросы - ответы.
1) Столкнулся с глюком CCS изза которого пришлось делать все через свою прогу 2го уровня. А точнее, вот создал я прошивку для OTP но при записи средствами CCS (F11) она не стартует после рестарта и разумеется плата с уже установленными пинами в отп загрузку. Но если я записую эту же прошивку своим загрузчиком 2го уровня, то все отлично(только для отп не делаю стирания перед записью). Выглядит как будто какойто косяк в CCS. Но чтото мне подсказывает что это не так. может встречались с таким?
2) Как быть? прошивку для OTP я слелал (допустим уже она финально отлажена) как теперь на производстве массово её прошивать, сотнями-тысячами в день? Вчера начальник сказал это вопрос тоже первостепенной важности и его нужно решить. Разумеется отдавать на завод исходники чтоб они компилили и прошивали, так это точно не способ. Вот как тут быть? Подскажите.
Сегодня нашел прогу C2Prog но чтото она не работает с моим эмулятором, так что проверить не смог. Какие еще есть варианты?

[doom13]

Все так, только за одним исключением, я прыгаю не на 0033fff6, а на EntryPoint, который мне сообщается в бинарике.

Ну это из даташита на Ваш процессор, по данному адресу должен лежать переход на _с_int00, при выборе старта с флэша. Если у Вас это другой адрес, то на него и совершаем переход.

Подскажите тогда сразу по ходу и на другие вопросы - ответы.
1) Столкнулся с глюком CCS изза которого пришлось делать все через свою прогу 2го уровня. А точнее, вот создал я прошивку для OTP но при записи средствами CCS (F11) она не стартует после рестарта и разумеется плата с уже установленными пинами в отп загрузку. Но если я записую эту же прошивку своим загрузчиком 2го уровня, то все отлично(только для отп не делаю стирания перед записью). Выглядит как будто какойто косяк в CCS. Но чтото мне подсказывает что это не так. может встречались с таким?

Вот тут подсказать не могу, с ОТР не работал. По-идее, должна быть возможность прошивки ОТП из CCS. Может какие настройки покопать? Не может ли это быть защищённой областью, где надо какие-нибудь галки или пароли прописать?

Тут, наверное, только google впомощь и на сайте TI можно попробовать вопрос задать.

Ещё раз просмотрел spraaq3 по поводу ОТР загрузчика, пишут, что стандартный On-Chip Flash Programmer должен уметь програмить ОТР память.

[PrSt]

Ну это из даташита на Ваш процессор, по данному адресу должен лежать переход на _с_int00, при выборе старта с флэша. Если у Вас это другой адрес, то на него и совершаем переход.

Не всё так просто, даже не учитывая лишние и не нужные действия CCSа 5.5.
Начну с того что я заметил и потом еще и понял.
-При записи OTP CCS5.5 делает совершенно лишнее действие - стирает секции флэша. Вот совершенно лишнее.
-А вот при повторной попытке перезапи OTP с другим адресом старта - оно дописывает биты по адресу старта для OTP 0x380400 - а вот это уже откровенный косяк, так как он то должен быть тоже однократно записываемый... короче я так запорол несколько чипов в экспериментах...
Потом этот идиотский _с_int00 - я нашел на него исходники и продебажил, спечатления что он вообще на фиг не нужен для OTP. Вообще вся библиотека rts2800_ml.lib уже несколько дней мне трахает мозги, по той причине что она не нужна для задачи OTP, вот вообщем как я понял. А еще то что она при выходе с main() перехватывает и отправляет в exit() от куда потом в abort() это рвет сохги в клочья. Короче пришлось сегодня писать хак на асме для непосредтвенного прыжка по адресу хранящемуся в переменной. Тоже кстати та ещё задачка, не зная асма этого проца...

Вот тут подсказать не могу, с ОТР не работал. По-идее, должна быть возможность прошивки ОТП из CCS. Может какие настройки покопать? Не может ли это быть защищённой областью, где надо какие-нибудь галки или пароли прописать?

Да я нашёл, оказуется там все просто, пока не обнаружил на днях выше описанный косяк в чипе не понял что это вообще у меня такое было.

Тут, наверное, только google впомощь и на сайте TI можно попробовать вопрос задать.

Вот чтото ТИ саппорт на многие вопросы не может дать ответа, судя по наблюдениям при поиске последних дней, видать у меня тоже били такое сложные вопросы... и часто даже они просто юлят, что в край было странною наблюдать.

Ещё раз просмотрел spraaq3 по поводу ОТР загрузчика, пишут, что стандартный On-Chip Flash Programmer должен уметь програмить ОТР память.

так и есть.

Делал свой бутлоадер кан для данного проца.
Как реализовал:
В флеше а хранил бутлоадер(после ресета прыгал туда).
Бутлоадер по состаянию кан линии либо передовал управление в области памяти C D либо программировал их.
В случае режима программирования получал во внутреннюю память бинарник и потом их массивами прошивал во флеш.
Бинарник получал через композер.
Его настраивал на формирование флеш имаже в формате hex.Далее hex перегонял в бинарник.
Единственной cmd файле надо правильно настроить адреса.

Я попытался тоже так сделал - но когда промучался пару дней с поиском вопроса на ответ, отказался и вернулся к ОТП. А проблема вот какая, когда ОТП-лайк прога в флэшн - её стандартный адрес BEGIN=0x38fff6, но кактолько она скача саму фирмвалю и написала то в BEGIN переписался тоже алрес старта, и разумеется наша ОТП-лайк прога уде ни когда не стартанет. В общем я не нашел и не придумал как это обойти (единственное было с мыслях парсить весь стрим и найдя этот пдоес тупо его игнорить и перехватывать для записи в другое место)
У меня весь стрим принимается по 2 байта и также и пишется сразу же по 1 слову. (Про эту находку я писал ранее)

Ваш вариант тут предлагался, но не получил одобрения со стороны создателя темы.

Я досе часто заглядую в Ваш код поискать чё нить полезное в качестве ответа на вопросы, и часто нахожу... )) Спасибо!

На "живом" процессоре часто бывают совсем другие результаты, чем на симуляторе или эмуляторе. Вот "типичный" пример.
Отлаживал программу, которая работала отлично при подключенном эмуляторе, но не работала "вживую". Вот что обнаружилось. Согласно документации, функция ExitBoot() в bootloader 28335 возвращает указатель стека на 0x400. Но в процессе проверки я нашел, что SP при выходе из загрузчика указывает на область ОЗУ M0. Так что, если в программе эта область используется под данные, можно поиметь проблему.
По основной проблеме. Писал почти такую же систему, с одним отличием - менеджер загрузки у меня SPI BOOT - читается из SPI Flash, проверяет флаг в I2C EEPROM, и так же предлагает залить новую прошивку или стартует старую из FLASH процессора. Я прочел Ваши посты, но не понял - Вы проверили весь FLASH, уверены, что по всем адресам Ваша программа через FlashAPI записала то, что нужно? Включая Entry Point? Попробуйте сделать верификацию прошивки через CCS3.

CCS3 не использую, меня от него коробит, кашмарный софт, не удобный ни разу. Но возможно таки прийдется тоже под него проект сделать.
"ExitBoot() в bootloader 28335 возвращает указатель стека на 0x400. " - О да, я несколько дней дебажил, и нашел виновника зла... - RTS2800_ml.lib. Пришлось сегодня писать хак на асме (основан на http://e2e.ti.com/support/development_tool...27/767892.aspx). "Но в процессе проверки я нашел, что SP при выходе из загрузчика указывает на область ОЗУ M0. Так что, если в программе эта область используется под данные, можно поиметь проблему." - ага, с похожим сталкивался тоже. По этому щас *.cmd линкер-файле разбрасываю секции памяти, это еще тоже отдельное "поле для экспериментов" кстати.

[doom13]

Я попытался тоже так сделал - но когда промучался пару дней с поиском вопроса на ответ, отказался и вернулся к ОТП. А проблема вот какая, когда ОТП-лайк прога в флэшн - её стандартный адрес BEGIN=0x38fff6, но кактолько она скача саму фирмвалю и написала то в BEGIN переписался тоже алрес старта, и разумеется наша ОТП-лайк прога уде ни когда не стартанет. В общем я не нашел и не придумал как это обойти (единственное было с мыслях парсить весь стрим и найдя этот пдоес тупо его игнорить и перехватывать для записи в другое место)

Не совсем понял, что Вы хотели этим сказать. Что адрес старта процессора всё время меняется? Так это не так, Вы сами задаёте этот адрес. Если Вы посмотрите мой проект для загрузчика и загружаемой программы (файлы .cmd), то найдёте, что там описывается кусок флэша с названием BEGIN на который ложится секция codestart. В секции codestart располагается асмовская инструкция перехода на _c_int00 (), т.е. на функцию main (см. DSP281x_CodeStartBranch.asm)

Код

code_start:
    .if WD_DISABLE == 1
        LB wd_disable      ;Branch to watchdog disable code
    .else
        LB _c_int00        ;Branch to start of boot.asm in RTS library
    .endif

Таким образом, не смотря на то что адрес main (_с_int00) может меняться, адрес перехода на _c_int00 всегда остаётся постоянным, и вы его сами задаёте, можете BEGIN положить по любому адресу, который Вам нравится.

Короче пришлось сегодня писать хак на асме для непосредтвенного прыжка по адресу хранящемуся в переменной. Тоже кстати та ещё задачка, не зная асма этого проца...

А как Вы до этого осуществляли переход? Всё просто, одна инструкция:

Код

__inline void GotoLoadedProgram(){ asm(" LB 0x3DA000"); }
__inline void GotoBootLoader(){ asm(" LB 0x3F7FF6"); }

[PrSt]

Не совсем понял, что Вы хотели этим сказать. Что адрес старта процессора всё время меняется?

У меня 2 уровня, Первый сам OTP, который грузит в ОЗУ вторую, промежуточную прогу, Второй - грузит фирмварю, вторая кстати и записывает её в флеш через флэшАпи. Так вот там адрес точки входа то может меняться, не исключено, ибо она а ОЗУ а а будущем неизвестно как всё повернется.

Так это не так, Вы сами задаёте этот адрес. Если Вы посмотрите мой проект для загрузчика и загружаемой программы (файлы .cmd), то найдёте, что там описывается кусок флэша с названием BEGIN на который ложится секция codestart. В секции codestart располагается асмовская инструкция перехода на _c_int00 (), т.е. на функцию main (см. DSP281x_CodeStartBranch.asm)

Код

code_start:
         .if WD_DISABLE == 1
             LB wd_disable ;Branch to watchdog disable code
         .else
             LB _c_int00   ;Branch to start of boot.asm in RTS library
         .endif

Таким образом, не смотря на то что адрес main (_с_int00) может меняться, адрес перехода на _c_int00 всегда остаётся постоянным, и вы его сами задаёте, можете BEGIN положить по любому адресу, который Вам нравится.

да, я знаю, я так пробовал, распалогал по адресу 0x8000 и от туда успешно грузился способом как вы написали ниже. Но как я уже писал адрес точки схода может поменяться.

А как Вы до этого осуществляли переход? Всё просто, одна инструкция:

Код

__inline void GotoLoadedProgram(){ asm(" LB 0x3DA000"); }
     __inline void GotoBootLoader(){ asm(" LB 0x3F7FF6"); }

Тут только константой задается, если передать вместо 0x3F7FF6 например _var_addr где будет храниться значение адреса, то по факту будет переход по адресу той самой переменной var_addr, а это точно не то, что мне нужно

Что-то я не понял последовательность в Вашем описании. У меня в cmd-файле для таких кусков записано неcколько описаний секций вроде этого:

Код

.text        :   LOAD = FLASHH, PAGE = 0
                       RUN = RAML0,    PAGE = 0
                       LOAD_START(WriterCodeLoad),
                       LOAD_SIZE(WriterCodeSize),
                       RUN_START(WriterCodeStart)

После старта мой загрузчик переписывает эти куски из FLASH в ОЗУ (memcpy, как в примере с FlashAPI) и передает туда управление. Эти куски, записанные в FLASH, из самого FLASH работать не могут, ибо содержат заведомо не те адреса, где лежат, а заточены под ОЗУ.

Если честно я не понял как оно у вас так работает. То что вы описали это классический подход к приложению в флеше. Ведь по идее точка входа даже в вашем случае будет гдето, но чтоб до неё добраться нужно пройти сквозь _c_int00, на адрес который то и будет указывать значение в 0x38fff6.

Так вот о чем я и говорил, что если вместо секции OTP, расположить нашу прогу(А), которая на самом деле OTP, только собранная для старта флеш, то будет её точка старта всё в том же 0x38fff6, и как только она скачает новую прошивку для флеша и перезапишет, то в том же 0x38fff6 уже будет указание не на (А) п на нашу новую прогу. Вот что я имел ввиду. И вот это как побороть я не понял, все пробы что делал не венчались успехом.

[Vladm]

Если честно я не понял как оно у вас так работает. То что вы описали это классический подход к приложению в флеше. Ведь по идее точка входа даже в вашем случае будет гдето, но чтоб до неё добраться нужно пройти сквозь _c_int00, на адрес который то и будет указывать значение в 0x38fff6.

Так вот о чем я и говорил, что если вместо секции OTP, расположить нашу прогу(А), которая на самом деле OTP, только собранная для старта флеш, то будет её точка старта всё в том же 0x38fff6, и как только она скачает новую прошивку для флеша и перезапишет, то в том же 0x38fff6 уже будет указание не на (А) п на нашу новую прогу. Вот что я имел ввиду. И вот это как побороть я не понял, все пробы что делал не венчались успехом.

Так. Давайте еще раз, с самого начала. У Вас в OTP записана программа-загрузчик (отдельный проект, со своим CMD-файлом). Процессор настроен выбором пинов на "boot from OTP", то есть точка BEGIN вашей проги-загрузчика, описанная в CMD-файле, всегда равна 0x380800. Программа записана раз и навсегда (так как OTP). Она откуда-то (неважно) читает какой-то параметр, и делает выбор - загрузить в ОЗУ кусок с FLASH API и передать туда управление для последующей загрузки и записи нового firmware (назовем его "основная программа" для однозначности) в FLASH, либо сразу передать управление в FLASH на уже ранее записанную программу.

Адрес точки входа (BEGIN) для FLASH всегда равен 0x33FFF6, он же указывается в CMD-файле при сборке проекта основной программы. А уже по этому адресу лежит переход (LB) на _c_int00 основной программы. То есть ваша программа-загрузчик при отсутствии необходимости обновления основной программы всегда передает управление по одному и тому же адресу 0x33FFF6. Что по этому адресу лежит, зависит от ранее прописанного из бинарника кода. А лежит там обычно "LB _c_int00", естественно, с абсолютным адресом, вычисленным при компиляции кода основной программы. Программе-загрузчику этот адрес знать не нужно - достаточно передать управление на 0x33FFF6.

Кусок программы-загрузчика для работы в ОЗУ расположен в проекте в отдельной секции, как и FLASH API, переносится из места хранения (OTP или FLASH, неважно) в ОЗУ через memcpy, адреса хранения в OTP/FLASH (LOAD) и перемещения/выполнения в ОЗУ (RUN) описываются в CMD-файле, как я написал ранее. Их можно задать жестко.

Ваша программа-загрузчик, выполняемая в ОЗУ, в случае необходимости обновления читает бинарник основной программы и пишет его содержимое по тем адресам, которые в нем указаны.

То есть все адреса известны заранее. Где наши методы (или понимание работы) расходятся?

[PrSt]

Так. Давайте еще раз, с самого начала. У Вас в OTP записана программа-загрузчик (отдельный проект, со своим CMD-файлом). Процессор настроен выбором пинов на "boot from OTP", то есть точка BEGIN вашей проги-загрузчика, описанная в CMD-файле, всегда равна 0x380800. Программа записана раз и навсегда (так как OTP). Она откуда-то (неважно) читает какой-то параметр, и делает выбор - загрузить в ОЗУ кусок с FLASH API и передать туда управление для последующей загрузки и записи нового firmware (назовем его "основная программа" для однозначности) в FLASH, либо сразу передать управление в FLASH на уже ранее записанную программу.

Адрес точки входа (BEGIN) для FLASH всегда равен 0x33FFF6, он же указывается в CMD-файле при сборке проекта основной программы. А уже по этому адресу лежит переход (LB) на _c_int00 основной программы. То есть ваша программа-загрузчик при отсутствии необходимости обновления основной программы всегда передает управление по одному и тому же адресу 0x33FFF6. Что по этому адресу лежит, зависит от ранее прописанного из бинарника кода. А лежит там обычно "LB _c_int00", естественно, с абсолютным адресом, вычисленным при компиляции кода основной программы. Программе-загрузчику этот адрес знать не нужно - достаточно передать управление на 0x33FFF6.

Кусок программы-загрузчика для работы в ОЗУ расположен в проекте в отдельной секции, как и FLASH API, переносится из места хранения (OTP или FLASH, неважно) в ОЗУ через memcpy, адреса хранения в OTP/FLASH (LOAD) и перемещения/выполнения в ОЗУ (RUN) описываются в CMD-файле, как я написал ранее. Их можно задать жестко.

Ваша программа-загрузчик, выполняемая в ОЗУ, в случае необходимости обновления читает бинарник основной программы и пишет его содержимое по тем адресам, которые в нем указаны.

То есть все адреса известны заранее. Где наши методы (или понимание работы) расходятся?

все именно так, только вместо 0x380800, должно быть 0x380400
А так, как раз Вами описан классический способ, и как раз подобного поста мне не хватало в начале всего этого пути...

Только отличие в том, что мне нужно не только грузиться по тому что в 0x38FFF6, но и возможно по совершенно другому адресу
самый простой пример, на чипе, в разные секции записаны разные версии, и нужно на них уметь перепрыгивать.
своего рода - мультибут, и главная особенность что точки старта у них могут меняться после перепрошивки каждый раз
То есть, цель сделать чуть более разумный и гибкий лоадер. что вобщем-то, мне кажется, удалось.

А лежит там обычно "LB _c_int00", естественно, с абсолютным адресом, вычисленным при компиляции кода основной программы. Программе-загрузчику этот адрес знать не нужно - достаточно передать управление на 0x33FFF6.

Вот тут то и проблема, была, которую я уже пофиксил, что в LD передается только константа... щас я могу гибко перепрыгивать в любое место которое узнаю при записи новой версии передав только переменную с значением точки бута.
Ну и второй момент, приложение может быть собрано в бинарик без всякого там _c_int00, а точнее без библиотеки rts2800_ml.lib, конечно это малая вероятность, но тем не менее не исключено тоже