[jcxz 183]

DSP нужно включить со стороны ARM'а - он выключается почти сразу после старта.

Хм... А что - в L138 первым стартует ARM?

Работал с L137 только - там стартует DSP (по вкл. питания ARM - в ресете) , код bootloader-а выполняет DSP, и в пользовательском ПО чтобы использовать ARM, надо сперва прописать таблицу векторов для ARM (в его памяти), а потом - включить его и вывести из ресета.

Под JTAG - на L137 доступны сразу оба ядра, так как JTAG их сам выводит из ресета когда подключается к ним. И на отладку под JTAG можно запускать сразу два проекта параллельно.

 

Понятно: процессор в user mode, поэтому и доступа к SYSCFG нет. Надо шерстить стартап StarterWare на предмет выставления режима.

rts.lib файл boot.asm:

cstartup: .asmfunc                                        
  MRS   R0, SPSR    ;Now will                  
  ORR   R0, R0, #CPU_MODE_SYS;set to SVC mode                  
  MSR   CPSR, R0    ;  with privileges

Можно конечно через SWI. Но я делаю как показал выше - так проще.

Кроме того - в этом rts.lib можно ещё что-нить пооптимизить и пообкусывать.

[torik 0]

Скачали с сайта техаса файл boot.asm, тупо добавили его в проект - все заработало.

 

Как это работает, каким образом этот асм файл встроился в код - непонятно совершенно.

 

А сигнальник все равно в ресете

 

На строках

 

     PSCModuleControl(SOC_PSC_0_REGS, HW_PSC_DSP, PSC_POWERDOMAIN_ALWAYS_ON,
             PSC_MDCTL_NEXT_ENABLE);

 

виснет. Какой порядок включения dsp? Разве не такой же как и GPIO?

[aaarrr 63]

Хм... А что - в L138 первым стартует ARM?

Там мудреная система загрузки: первым стартует DSP, затем он при помощи PRU окучивает ARM, потом ARM отрубает DSP.

 

Какой порядок включения dsp?

Порядок включения описан в разделе "DSP Wake Up" sprugm7. Но виснуть при обращении к PSC всяко не должен.

[maxis 0]

Порядок включения описан в разделе "DSP Wake Up" sprugm7. Но виснуть при обращении к PSC всяко не должен.

 

По мануалу:

 

Perform the following steps to wake up the DSP:

1. Write a 83E7 0B13h to the KICK0R register in the SYSCFG module.

2. Write a 95A4 F1E0h to the KICK1R register in the SYSCFG module.

3. Write the truncated DSP boot address vector to the DSP_ISTP_RST_VAL field in the host 1

configuration register (HOST1CFG) of the SYSCFG module. The least-significant bits of the boot

address are fixed at 0.

4. Write a 3h to the NEXT bit in the DSP local power sleep controller (LPSC) module control register

(PSC0.MDCTL15) to prepare the DSP module for an enable transition (to enable the clocks and all

transitioning from the SwRstDisable state to Enable state).

5. Write a 1 to the GO[1] bit (DSP subsystem is part of the PD_DSP domain) in the power domain

transition command register (PSC0.PTCMD) to start the state transition sequence for the DSP module.

6. Check (poll for 0) the GOSTAT[1] bit in the power domain transition status register (PSC0.PTSTAT) for

power transition sequence completion. The domain is only safely in the new state after the GOSTAT[1]

bit is cleared to 0.

7. Wait for the STATE bit field in the DSP LPSC module status register (PSC0.MDSTAT15) to change to

3h. The module is only safely in the new state after the STATE bit field changes to reflect the new

state.

8. Write a 1 to the LRST bit in PSC0.MDCTL15 to release the DSP local reset controlled by the PSC

module.

 

Выполняю следующее:

 

    HWREG (SOC_SYSCFG_0_REGS + SYSCFG0_KICK0R) = 0x83e70b13;
    HWREG (SOC_SYSCFG_0_REGS + SYSCFG0_KICK1R) = 0x95a4f1e0;

    //Включение DSP
    HWREG (SOC_SYSCFG_0_REGS + SYSCFG0_HOST1CFG) = 0x00E00000;
    PSCModuleControl(SOC_PSC_0_REGS, HW_PSC_DSP, PSC_POWERDOMAIN_PD_DSP, PSC_MDCTL_NEXT_ENABLE);
    PSCModuleControl(SOC_PSC_0_REGS, HW_PSC_DSP, PSC_POWERDOMAIN_PD_DSP, PSC_PTCMD_GO1);
    PSCModuleControl(SOC_PSC_0_REGS, HW_PSC_DSP, PSC_POWERDOMAIN_PD_DSP, PSC_PTSTAT_GOSTAT1_SHIFT);
    PSCModuleControl(SOC_PSC_0_REGS, HW_PSC_DSP, PSC_POWERDOMAIN_PD_DSP, PSC_MDSTAT_STATE);
    PSCModuleControl(SOC_PSC_0_REGS, HW_PSC_DSP, PSC_POWERDOMAIN_PD_DSP, PSC_MDSTAT_LRST);

 

И на строке

PSCModuleControl(SOC_PSC_0_REGS, HW_PSC_DSP, PSC_POWERDOMAIN_PD_DSP, PSC_MDSTAT_STATE);

Выполнение программы подвисает. Что делаю не так?

[aaarrr 63]

И на строке

PSCModuleControl(SOC_PSC_0_REGS, HW_PSC_DSP, PSC_POWERDOMAIN_PD_DSP, PSC_MDSTAT_STATE);

Выполнение программы подвисает. Что делаю не так?

А что говорит PSC0.MDSTAT15?

[maxis 0]

А что говорит PSC0.MDSTAT15?

0x00000A00

[aaarrr 63]

То есть по статусу он и не начинал включаться. Нужно смотреть внутренности PSCModuleControl, так у меня идей нет.

[jcxz 183]

Там мудреная система загрузки: первым стартует DSP, затем он при помощи PRU окучивает ARM, потом ARM отрубает DSP.

Значит - всё точно так же как в L137.

А зачем Вы отрубаете DSP после старта ARM?

Если интересно могу привести свой код, которым запускаю ARM (см. прикреплённый файл).boot.zip Файл boot.asm (который в составе rts.lib) модифицирован как указано в моём посте выше.

Начало main() из DSP-проекта:

#pragma FUNC_NEVER_RETURNS
int main()
{
  u32 cpuUseIdle;
  s32 i;

  CACHE.L1DCFG = 7;
  i = CACHE.L1DCFG;
  soc.faza = soc.FAZA_BEGIN;
  EnableARM();

  CooperateWait(soc.FAZA_DSPIDLE_MEAS); //отсель ARM и DSP работают совместно
  ...

[aaarrr 63]

Значит - всё точно так же как в L137.

Нет, совершенно по-другому. DSP после старта отрубает программа из ARM Boot ROM.

[SM 0]

Значит - всё точно так же как в L137.

 

Это и есть основное, если даже не единственное отличие 137 и 138 - в 137 стартует DSP с заглушенным ARM, а в 138 наоборот, стартует ARM с заглушенным DSP.

[jcxz 183]

Это и есть основное, если даже не единственное отличие 137 и 138 - в 137 стартует DSP с заглушенным ARM, а в 138 наоборот, стартует ARM с заглушенным DSP.

Да уж, нагородили ... техасцы на ровном месте.....

Думаю, что у L138 тогда более логичный порядок старта. Всегда удивляло - зачем в L137 сделали главным в запуске DSP?

Кстати - не единственное - для нас существенным доводом в пользу L137 против L138 стало наличие в первом McASP (в L138 - только McBSP).

[SM 0]

Всегда удивляло - зачем в L137 сделали главным в запуске DSP?

Все просто. Есть задачи, где ДСП молотит всегда, а АРМ у него на подручных работах - TCP/IP например. Там не надо, чтобы АРМ стартовал первым, ДСП в него грузит нужные протокольные уровни и работает через него как через сопроцессор связи. Там L137 удобен - так как ДСП грузится первым и дальше мастерит всеми процессами. А есть другие задачи - где АРМ работает например под линуксом, а ДСП у него на подручных работах - кодек загрузить, когда юзер захочет. Вот тут L138 самое оно.

[aaarrr 63]

На самом деле в L138 первым тоже стартует DSP, просто от конечного пользователя вся эта кухня скрыта.

 

И в нем есть McASP, куда же без него.

[SM 0]

На самом деле в L138 первым тоже стартует DSP

Конечно, точно не могу утверждать, но косвенные признаки показывают, что это не так. Если выполнить hardware reset через JTAG при помощи ICEPICK, и не дать ядрам выполнить ничего из внутреннего ПЗУ, то живым в L138 оказывается таки ARM, а в L137 - DSP. И это же следует из анализа стартапных GEL-файлов обоих процессоров, и последовательностей коннекта эмуляторов к ядрам.

[aaarrr 63]

Вот цитата из errata, касающаяся ревизий 2.0 и ниже:

For affected silicon revisions, the DSP initiates the system boot sequence when the

device is released from reset. Before the ARM can take control of the user boot mode,

the DSP must first initialize the ARM reset vector table so that the ARM will execute from

its boot ROM.

Возможно, в 2.1 последовательность поменяли, хотя проще было бы пропатчить DSP boot ROM.