AnsweredAssumed Answered

Can not boot BF561 from 16 bit flash

Question asked by rf247 on Sep 12, 2017
Latest reply on Sep 12, 2017 by rf247

This is rather long but in a nutshell I can not seem to get code for BOTH cores of the BF561 project I have to load and run from a LDR image in 16 bit flash at the traditional 0x20000000 location. Additionally, when I dial it back and simplify the objective and just try to get CoreA loaded and started that does not load and start either. I have multiple single core flash boot projects behind me but with the BF561 I can not seem to get it to load and run in either single or dual core mode.

 

Here are all the details

 

I have a BF561 dual core project that is a migration of a old fully vetted BF538 project to the dual core platform. Only purpose was to get more bandwidth since the last platform ran out of gas after stuffing one thing too many in to the older platform. The code was migrated and debugged on the BF561 EZKIT. It runs well on that platform. That code in turn was tweaked to run on the new target hardware which is virtually identical to the old hardware except the processor is BF561 rather than BF538.. I am able to load and run the resultant code on the new target hardware using a jtag - USB ICE emulator. Everything runs as expected. The PLL clock settings and the EBIU_... SDRAM settings come from the XML file as is custom when using an emulator. The code loads in to the target Cores A & B internal L1 & L2 SRAMs and in to the external SDRAM all as expected if a emulator is used. Code runs well using the emulator to load and run it.

 

The final step is to concatenate the 3 DXE codes in to a single LDR that can be burned in to and loaded and run from ASYNC0 address 0x2000 0000 flash. This would seem to be a "simple" process but this is where I am stalled. This process is similar to the multiple single core projects I have done in the past except instead of pre-pending the InitSDRAM code to a single core DXE it is pre-pended to CoreA + CoreB DXE's. I used the elfloader command as follows to concatenate the 3 salient DXE files to create a "single" LDR consisting of

 

pre-pended BF561_InitSDRAM - This is the usually-tiny assembly routine that is called by the on-chip boot Kernel prior to loading the real application code. It sets up the SDRAM register values and the PLL clock rates so that SDRAM code and data can be safely loaded. This code is loaded internal SRAM at 0xFFA00000 and run and it does its job as expected. This code is based on fully vetted prior projects and I have confidence in it because the UART diagnostics that it outputs are pretty definitive that it is doing its simple job as expected. It works exactly as it always has in past projects that are currently field deployed and sold to customers. I added diagnostic code to this to exhaustively test the SDRAM so I am pretty confident the SDRAM and clock are set properly. Plus the settings are the same as the settings from the XML file that is used when the emulator is used.

 

CoreA DXE. After the previous code is run the boot kernal is supposed to load the next DXE code which is the CoreA DXE. Every indicator I can gather says that the CoreA code and data is being loaded But the problem is it never runs. More on that later

 

CoreB DXE. After CoreA is loaded CoreB is supposed to be loaded. A LDR viewer tool I have indicates that the 3 DXE's have been concatenated in order and best I can ascertain they have the proper format. I.e. the first DXE is prepended with the magic "global header" of 0xA00000DF and each DXE is linked in the proper way. Both the LDR loader and painstaking visual inspection with a binary viewer seem to confirm that the format of the LDR is OK (but of course I can not guarantee. Hard to visually inspect reams of binary). The -nosecondstagekernel and and -NoFinalTag  options in the elfloader command seem to suppress the automatic inclusion of a second stage loader (as desired) and make sure the CoreA dxe does NOT get the final tag so that CoreB can be loaded after CoreA. CoreB, the last DXE has the final tag as expected.

 

So the LDR image I am burning to flash looks OK to me. But its not working else I would not need help:)

 

The magic "the DXE concatenation command line I use looks as follows"

 

elfloader.exe  -proc ADSP-BF561 -v -init ..\CoreA\BF561_InitSDRAM.dxe -nosecondstagekernel -NoFinalTag  ..\CoreA\Release\CoreA.dxe ..\CoreB\Release\CoreB.dxe -b Flash -f binary -Width 16 -o ..\CoreA\Release\CoreAPlusCoreB.ldr

 

The command above is rather complicated but it looks right to me and it seems to produce the expected CoreAPlusCoreB.ldr image. Since it is hard to find explicit SUCCESSFUL examples of this sort of command I can't guarantee my command is correct. But the output sure looks correct.

 

So best I can discern the total InitSDRAM+CoreA+CoreB LDR is in a proper and expected format. But for some reason CoreB never seems to load and CoreA start code never gets run. What most bothers me is that the boot kernel never even jumps to the start location. I think I could debug the application if I got that far but the code load process seems to disappear in to the inscrutable black hole of the boot kernel.

 

At this point I am not looking for perfection. I am only looking for some sign of life so I can debug the code load.

 

It is as if

 

1. InitSDRAM is loaded and run by the boot loader as expected

2. CoreA DXE is loaded to CoreA and shared spaces as expected but never gets run

3. CoreB DXE never gets loaded OR run because CoreA must run before CoreB can run

 

From the outside it looks like some where during or at the end of step two above (or at the start of step three) the on-chip boot kernel goes in to some sort of "forever freeze" and that is the ball game. Since there is little to no visibility in to the boot kernel its hard to know what happened. I studied the available boot kernel assembly (found in the visualDSP 5;1;2 tools) and can see that if evil happened it could get locked in IDLE or some such horror. But exactly IF that is happening and/or what may have caused it is very difficult to diagnose.

 

Has anyone ever experienced this? I know of no way to step through the on chip boot loader to find where it is freezing up. If there is a error in the LDR image being able to see where it is locking up would be of immense help. When I reconnect with the emulator I can see that the CoreA program image was loaded but I have proven that it never runs because I have LED turn-on code as the first few assembly instructions of the magic 0xFFA00000 CoreA start location. I have added extended register dump diagnostics to the InitSDRAM code which always loads and runs seamlessly as expected. Nothing at that stage looks out of order. But obviously something is out of order else it would run

 

When I try to disassemble and/or step through the on-chip boot kernel located at 0xEF000000 the emulator misbehaves and is of no use.

 

I am not very much of a hardware guy but I am quite experienced in firmware including assembly. I do however have hardware geeks at my disposal if it is necessary to probe the electrons. The fact that the code runs using the emulator seems and that the initSDRAM code loads and runs from flash seems to indicate the hardware is pretty solid. I have multiple Blackfin projects behind me including writing and debugging flash boot code - load. Nothing has gotten the best of me the way the BF561 has. The target hardware seems functional as evidenced by the fact that it runs the code fine once it is loaded and run using an emulator. At this point I am running out of ideas on what to try next.

 

Is it possible that I need to go the Second Stage Loader route? The documentation I have read indicated that should not be necessary but after looking at the boot kernel assembly code I am not so sure. I expected to see the boot kernel use the IMDMA controller but I have not seen it. So maybe I have been trying to do something that is just not possible. I was expecting to just burn a LDR image similar to the way I have done in past projects and the boot kernel would run the initSDRAM and treat the CoreA+CoreB images as a single boot stream. So far no joy.. If anyone has any ideas I would be appreciative.

Outcomes