rom.bin does not work when FLASH used for NVRAM

I am trying to update our application from NetOS4 to NetOS5 so i can use Flash for NVRAM. Under Netos4 we used an 8K eeprom and we want to go to using Flash for NVRAM so we can have additional space. I added the define to bspconf.h BSP_USE_FLASH_FOR_NVRAM. everything works great when i use the debug build and download to ram with the raven, but when I build a rom.bin file from the rom.bld, and download it using the naftpapp example it fails to boot, it doesn’t even get to the point where it launches the netosstartup thread. If I build the rom.bin using a bsp without BSP_USE_FLASH_FOR_NVRAM defined and download it, it boots and works correclty. What am i missing? Is there something else in the BSP I have to change? I am using NetOs V5.0 with Greenhills 3.5. I have also tryed this same thing using the nahttp example included with NetOS5 with the same results. Please help. We are using a Net40 and AMD Flash. This is on our own custom board that we have been using for over a year now with NetOS4. Any Ideas??

• To use FLASH as NVRAM define BSP_USE_FLASH_FOR_NVRAM in bspconf.h. Then rebuild bsp.bld • The first BSP_NVRAM_SIZE (defined in bspconf.h) bytes of the last sector of FLASH will be used as NVRAM. • Make sure BSP_NVRAM_SIZE is not larger then the last sector of FLASH. • It is the users responsibility to protect the last sector from being overwritten or erased. • NAFlashInit() must be called prior to NANVInit. • In NANVInit, if using FLASH as NVRAM, the parameters are ignored.

Hi,I have exactly the same problem Blake described here. I wonder if you or anyone else have solved the problem? I have checked all the points that Muselman replied, but still don’t work. Thanks Minlin

I have not solved the problem with using the flash as NVRAM but I have solved the problem with rom.bin not booting. Netsilicon don’t seem to understand that you can’t execute from FLASH and write to flash at the same time. Executing from RAM is no problem but when using rom.bin the program is executed from FLASH which makes using the FLASH as NVRAM not possible unless you execute the actual FLASH procedure from another memory. /Jesper

I can use Flash as NVRAM fine but only in the debug mode. It won’t work when I build rom.bin version and it doesn’t boot from Flash correctly. My understanding is that the rom.bin doesn’t execute from Flash but copy code to SDRAM then execute still from SDRAM.

If you want the image to execute from ram I do not understand why you do not use image.bin which does exactly that !? If the image shall be executed from flash or ram depends on the bootldr.dat file in the linkerScripts directory. The file looks something like this: WriteToFlash Yes Compressed Yes ExecuteFromRom No flashOffset 0x10000 ramAddress 0x800000 MaxFileSize 0xD0000 Netsilicon uses a tool, boothdr, which adds a header to the generated image. The booloader then reads this header to know what to do with the image i.e. unpack it if it is compressed and if it should load it to ram or execute it directly (i.e execute from flash). If you look in the Makefile the ram image (image.bin) is generated with the flow: $(OBJCOPY) -Obinary $(DEBUG_VERSION) $(UNCOMPRESSED_IMAGE) $(COMPRESS) $(UNCOMPRESSED_IMAGE) $(COMPRESSED_IMAGE) $(BOOTHDR) $(HEADER_CONFIG) $(COMPRESSED_IMAGE $(IMAGE_WITH_HEADER) This generated image works together with the bootldr.dat file above. But it is very important that the linkfile used with the image is correct since the image is loaded to a ram address defined in the bootldr.dat file and not in the image file!! The defualt genaration of the rom.bin image is (at least in 5.1 that I use): $(OBJCOPY) -O binary $(ROM) $(ROMBIN) This image is not compressed and has no header. The bootlaoder can not handle this image. This image can be used without the booloader (which is not a good idea) or a header can be added to the image. If you want it to execute from flash (which I do) you have to make sure that the linkfile links the rom.bin to the correct flash address, modify bootldr.dat and add a header to the rom.bin file. Hope this answers your question. /Jesper

Thanks for giving me these details, Jesper. They are useful. I think you are talking NETOS5.1 onward which has bootloader support. I was using NETOS5 still but now I am going to use NETOS6 and get the bootloader working. I was told by Netsilicon techsupport that using bootloader facility will enable “USE_FLASH_AS_NVRAM”. But this means I have to modify quite a bit of my code to migrate to NETOS6. The BSP has changed quite a lot hasn’t it? Minlin

I am using NETOS5.1 but I have looked a little bit on 6.0. In my case the benefits was not worth it to change to 6.0…yet. I have had to write a DHCP client, since you can’t control the options and it does not try to get a get a new IP if the IP is lost (not fixed in 6.0), and made quite many of my own changes in the BSP etc so to have to do all that over again takes too much time at this point. Most of these changes can probably be used in 6.0 but they have moved many of the functions to other files. /Jesper

Just a quick one. The bootloader allows automatic firmware downloading from BOOTP server when the existing one is faulty. But can I do a normal flash upgrade even the existing firmware is fine. how? Minlin

I dont use the default bootloader. I have modified the bootloader to enabel firmware-upgrade by RS232, RS485 or UDP/IP but I use the same principal. There are a few solutions to your problem. As I understand it your program executes from RAM so your main program can have the functionality of writing to flash. You could, for example, add a ftp server to your main program which writes to flash (one of the supplied examples can be used). Or you can write your own driver depending on how you prefer to upgrade the system. If the upgrade is caused by a specific event you can simply “destroy” the stored image by changing a byte or two, reset the system and the bootloader will get a new image. Which solution that is best for you depends on your demands. My communication is AES-crypted with a specific protocol and the boards does not have to have ethernet so in my case I did not have that much of a choice than to modify both the bootloader. Hope this helps a little bit. /Jesper

Very good to know you have actually done it to modify the bootloader. Thanks for your advice. I think I am going to too to enable the bootloader to upgrade flash firmware via RS232 and FTP. I have a quick look at \src\bsp\bootloader. Is that possible to give me some hints where to start modifying this bootloader? Cheers. Minlin

When it comes to RS232 you more or less write an ISR that handles incoming data. I don’t know if you can use the Netos drivers but they are quite large so I wrote my own. I don’t want the ram image to be started if the image is correct so i modified the rom image to verify the image instead of the ram image. Simply moved these routines to the rom image. If the FTP upgrade shall be done with TFTP and BOOTP i don’t think you have to change very much, if anything. But if you want the bootloader to be a FTP-server I think you have to write your own FTP server since the Netos FTP server API is not made to run from the bootloader. I use UDP packets but then you have to write your own upgrade software since there is no standard protocol if you do not use FTP. If you are going to upgrade by RS232 you probably have to have a protocol to handle that anyway. I use the same protocol for both RS232, RS485 and UDP/IP (the delivered bootloader in 5.1 does not support TCP!) so that i can use the same routine in the bootloader to handle the received packets which make the bootloader small and simple. Note that the bootloader is not multithread so there is only a main loop and ISR routines. /Jesper

Thanks for the hints. I must mark them down.