Disassembling a binary using GNU tools on a weird architecture

objdump -D Release/tinyloader.bin --target=binary --architecture=xscale

The -D option is key. You can't use -d, since you are starting with a binary file that has no sections. The -D option ignores sections and disassembled everything.

How to install a bootloader on a STR912 without CAPS or Raisonance

ST recommends CAPS (their GUI) to install the STR912. However, that requires a Raisonance JTAG adapter. You can do it with just IAR EWARM and Segger tools.

1. Download the JLINK software from Segger.com
2. Run "J-LINK STR9 Commander" tool (it's under Segger-> JLink ARM 3.95a -> Processor Specific Utilities).
   
3. Type "?" to get a list of commands
4. Type "erase all" to fully erase the chip.
5. Type "setb 1" to set the boot bit to bank 1.
6. Type "q" to quit.
7. Now you can use the flash loader of EWARM to install the code.

You can also use the "secure" command to secure the JTAG port, but that makes debugging via JTAG impossible. :)

Adding an external file to a perl module

Let's say you want a perl module to scream "argh" on failure. You find a argh.wav file and want to bundle it with the perl pm file. The problem is loading the wav file without knowing the full path. Perl's current working directory can be any where, and the location of the wav file or module file may not be in the same location as the starting pl file. To find the starting pl file, you can use the FindBin::Bin module, but this doesn't work for modules. If you want to know the location of the module (pm) file instead, you can use the %INC hash to get it. This hash value gets set when you "use" the pm file. Once you know where the pm file is, you can use the dirname() function to get the directory name, then add the name of the wav file.

Here is an example (in a perl module called "Scream.pm"):

use File::Basename;
use Win32::Sound;

my $wavfile = dirname($INC{"Scream.pm"})."/argh.wav";
Win32::Sound::Play($wavfile);

Tools for mocking-up C++ classes

I haven't played with this yet, but it seems to have its heart in the right place.

http://code.google.com/p/googlemock/wiki/ForDummies

Neat source of icons

I stumbled upon this cache of free icons if you follow the LGPL.


http://commons.wikimedia.org/wiki/Crystal_Clear

Don't use a virtual function in a constructor

Virtual functions should be used until an object is fully constructed. That is because the constructor builds the virtual function table in pieces. When it is constructing the base class, the derived class virtual function table is not yet constructed. So if you call a virtual function, you are calling the virtual function of the base class not the derived class. This is worse if the base class is a pure interface, ie the virtual functions are declared as pure (ie " =0;"), because you can't call a pure function -- the pointer points to NULL and your program crashes.

STR91x bootloader trouble, PFQ/BC

Most start-up code (91x_init.s for example) writes 0x191 to the SCU->SCR0 register, which among other things enables the PFQ/BC (Pre-Fetch Queue/Branch Cache). This is normally a good thing. Of the 16 entries in the Branch Cache, 15 are used for generic branches while the 16th one is used only for the special IRQ branch at address 0x18. It appears that this branch cache value is initialized when the PFQ/BC is turned on AND read-only after that. That means if the jump at 0x18 changes, the BC entry will be wrong.

Why would the jump at 0x18 ever change? It changes if you remap the banks, i.e. use BANK1 as the bootloader boot bank, and then switch to BANK0 as the main application. Of course, you shouldn't even do this if you are not using at least rev H of the STR912FAW, but that is a different story (the chip reset circuit has a bug that makes this impossible).

What happens if you don't do something special a programmer's worst nightmare: jumps are random when you let the program run, but if you step through the ASM code, it works fine (because the cache is turned off if you are doing single steps). And the random jumps are not a software bug that you can fix.

But there is a fix. Change the boot code to disable the PFQ/BC, then reenable it later in your code.

; --- Enable 96K of RAM  & Enable DTCM & AHB wait-states, disable PFQ/BC until it is flushed. The bootloader has cached the IRQ already and that is BAD!
        LDR     R0, = SCU_BASE_Address  
        LDR     R1, = 0x0196  ; not 0x0191 as in other boot code!
        STR     R1, [R0, #SCU_SCR0_OFST]

Later you can reenable using the 91x_lib call (inside __low_level_init() if you are using IAR EWARM):

  SCU_PFQBCCmd(ENABLE);     // Enabled Branch Cache feature of STR91x.