• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Calibration data

sharikov

Active member
Здесь пишут что нужно сохранять калибровочную область с 0x9000 по 0xAFFF
  • You can programming the RTL8710 via J-Link and other CMSIS DAP, but you don't erase MAC address and WLAN calibration data in 0x9000 - 0xAFFF.
  • Realtek's DAP firmeware prevents to erase 0x9000 - 0xAFFF.
Флэшер от rebane в явном виде оперирует только с mac адресом.
Кто нибудь озадачивался сохранением с мак и калибровок ?
Вообще калибровки wifi и mac во флэш это косяк со стороны Realtek - при перепрошивке их слишком легко потерять.
 

goodwin

Member
Как раз экспериментирую с J-Link API...
Увидел этот пост и прикрутил такую кнопку...
С другой строны можно просто сохранить FullFlash и выдернуть оттуда, что нужно.
Это приблудка на дельфях (ну не люблю я лишние линукс причиндалы в WIN).
Требуется JLinkARM.dll свежих релизов. Ну и "народный" J-Link.
 

Вложения

Последнее редактирование:

sharikov

Active member
С другой строны можно просто сохранить FullFlash и выдернуть оттуда, что нужно.
Это приблудка на дельфях (ну не люблю я лишние линукс причиндалы в WIN).
Внешняя приблудка ненадежна - после 100500-й перепрошивки (не всегда удачной) калибровка неизбежно будет потеряна. Если калибровочные данные действительно важны (и мак впридачу) их стирание и запись нужно выжигать напалмом везде: во флэшере и в SDK напрочь вырезать запись в эту область, никогда не использовать для стирания чипа его команду erase all а стирание в зоне калибровки выполнять 4-х килобайтными блоками для обхода калибровочной области.
Очередное "поле с граблями".

PS.
ну не люблю я лишние WIN причиндалы в линукс
gcc, make, eclipse, openocd заточены на линукс. в чуждой им винде они запускаются с костылями и работают хуже чем в родной среде.
 

goodwin

Member
Ваш постулат "после 100500-й перепрошивки (не всегда удачной) калибровка неизбежно будет потеряна" не стыкуется с последующими словами ;) Так что заныканный в укромное место файлик с калибровками будет не лишним, если модуль планируется для 100500 издевательств :)
 

pvvx

Активный участник сообщества
Главный вопрос так и не вычислен:
А нужны ли эти калибровки? :)

В указанных секторах сохраняются калибровки ADC и прочей шелухи связанной с SDK Амёба.
Для самого модуля и его ROM-BIOS они не нужны.
При стирании этих секторов в Амёбе устанавливается Реалтековский MAC, а не китайский, от продавца, загнавшего прошивку. :p
С таким же успехом вы можете прописать туда свой выдуманный MAC или установить его через AT команды в Амёбе...
ADC и прочей шелухи в RTL00 нет -> калибровки не требуются. Тем более в SDK есть процедуры калибровки...
 
Последнее редактирование:

pvvx

Активный участник сообщества
Судя по этому lib_wlan.a: rtl8195a_hal_init.o rtw_flash_map_update():
Код:
signed int __fastcall rtw_flash_map_update(PADAPTER padapter, uint8_t *configTbl)
{
  PADAPTER v2;
  signed int result;
  signed int v4;
  uint16_t magic_number;
  uint16_t data_addr;
  uint16_t data_len;
  flash_t flash;

  v2 = padapter;
  device_mutex_lock(1, configTbl);
  flash_stream_read(&flash, 0xA000, 2, &magic_number);
  if ( magic_number == 0x8195 )
  {
    v4 = 2;
    do
    {
      flash_stream_read(&flash, v4 + 0xA000, 2, &data_addr);
      if ( data_addr == 0xFFFF )
        break;
      flash_stream_read(&flash, v4 + 0xA002, 2, &data_len);
      if ( data_len == 0xFFFF )
        break;
      if ( data_addr + data_len > 4096 )
        goto LABEL_2;
      flash_stream_read(&flash, v4 + 0xA004, data_len, (char *)v2 + data_addr);
      v4 += data_len + 4;
    }
    while ( (unsigned int)v4 < 0x1000 );
    device_mutex_unlock(1);
    result = 1;
  }
  else
  {
LABEL_2:
    device_mutex_unlock(1);
    result = 0;
  }
  return result;
}
Если нет метки 0x8195 по адресу 0xA000 в Flash, то берутся значения по умолчанию.
 

pvvx

Активный участник сообщества
Как раз экспериментирую с J-Link API...
Увидел этот пост и прикрутил такую кнопку...
А можно сделать полный программатoр или кинуться исходниками имеющейся "приблудка на дельфях" (можно и в личку)?
У меня пока такой программатор в проекте c Амёбой, использует gdb, не пишет "калибровочные" сектора, т.к. разбирает заголовоки у ram_all.bin и пишет только image1 и image2.
Исходники/файлы "программатора":
JLinkGDB-WrFlash.bat
gdb_wrflash.jlink
gdb_flasher.jlink
rtl8710_flasher.bin
Но это не универсальное решение и для каждого проекта надо вписывать в gdb_wrflash.jlink имя файла и т.д.

И ещё вопрос: Кто подскажет, как в скрипте gdb узнать размер файла или как gdb передать параметры для скрипта?
 
Последнее редактирование:

goodwin

Member
Сделать желание есть, нет времени, а порой и "сала в голове" :)
Пока это просто тест на дельфях, испольующий тот же "хак" с включением Flash в адрес 0x98000000.
Для "прошиватора" можно заюзать тот же stub от GDB.
Вот, собственно, и весь "исходник":
Код:
procedure TForm1.Button1Click(Sender: TObject);
var
   I : DWORD;
   RegValue : DWORD;
   time_beg: integer;
   NumWritten: integer;
begin

  Button1.Enabled:=False;
  Button2.Enabled:=False;
  res:= JLINKARM_Open();
  if res = 1 then
   begin
   Beep;
   ShowMessage('J-Link not found!');
   Halt;
   end;
  res:= JLINKARM_ExecCommand('device Cortex-M3',0,0);
  res:= JLINKARM_TIF_Select( 1 );
  res:= JLINKARM_SetSpeed(1000);
  res:= JLINKARM_Reset();
  res:= JLINKARM_Halt();

  sleep(10);
  res:=JLINKARM_IsConnected();
  if res = 0 then
   begin
   Beep;
   ShowMessage('RTL8710 not found!');
   Halt;
   end;

  label1.Caption:='Rеading FullFlash...';
  Application.ProcessMessages;


  res:=JLINKARM_WriteU32($40000230, $0000D3C4);
  res:=JLINKARM_WriteU32($40000210, $00200113);
  res:=JLINKARM_WriteU32($400002C0, $00110001);

  res:=JLINKARM_WriteU32($40006008,0);
  res:=JLINKARM_WriteU32($4000602C,0);
  res:=JLINKARM_WriteU32($40006010,1);
  res:=JLINKARM_WriteU32($40006014,2);
  res:=JLINKARM_WriteU32($40006018,0);
  res:=JLINKARM_WriteU32($4000601C,0);
  res:=JLINKARM_WriteU32($4000604C,0);

  res:= JLINKARM_SetSpeed(4000);
  res:= JLINKARM_GetSpeed();

  time_beg:= GetTickCount;

//  for cnt:=0 to $100000 do  buf[cnt]:= $FF;
//  res:=JLINKARM_WriteMem($98000000, $100000, buf);

  res:=JLINKARM_ReadMem($98000000, $100000, buf);
  label1.Caption:= 'FullFlash saved to RTL8710_ff.bin, Time: '+ IntTostr(GetTickCount-time_beg) + 'ms, Speed: '+ IntTostr(($100000 div(GetTickCount-time_beg)))+ ' KBytes/s';
  beep;

  res:=JLINKARM_WriteU32($40000210, $00211157);

  res:= JLINKARM_Reset();

  res:=JLINKARM_Close();
{$I+}
  AssignFile(F,'RTL8710_ff.bin');
  Rewrite(f);
  BlockWrite(F, Buf, $100000, NumWritten);
  CloseFile(f);
{$I-}

  Button1.Enabled:=True;
  Button2.Enabled:=True;
end;
И юнит "jlinkarm.pas", найденный в сети...
 

Вложения

pvvx

Активный участник сообщества
Сделать желание есть, нет времени, а порой и "сала в голове" :)
Аналогично - на всё времени нет, потому всё что кинуто - сделано кое-как :)
Спасибо за исходник...
Пока это просто тест на дельфях, испольующий тот же "хак" с включением Flash в адрес 0x98000000.
После включения этого "хак" запись в область Flash тоже работает. Но как сделать стирание сектора пока не выдумал. Можно через регистры SPIC, но пока лень....
 
Последнее редактирование:

goodwin

Member
Да, что можно писать "0" тоже увидел (там пара закомментаренных строчек) - как же не попробовать :)
Со cтиранием проблема.
А исполнение кода их этой области не довелось проверить?
 

pvvx

Активный участник сообщества
Со cтиранием проблема.
Нет там проблем - набивать код надо, а когда?
А исполнение кода их этой области не довелось проверить?
Только в отладчике - шагает... Но отладчик может копировать команду при пошаговом...
Проверку скорости чтения байтиков из области flash делал - неутешительно: более 130 тактов CPU на байт.
Болванку flasher-а набил, добавил все команды... Кинул в теме - Кто доделает Flasher для RTL00 c JlinkARM.dll?
 
Последнее редактирование:
Сверху Снизу