I am trying to create a MAC driver to be able to download code to cypress parts. I can successfully send data to the RAM and read it back. There is one restriction that is listed in the cypress part. I can send any number of bytes but it only works if the first address is a word boundary (evenly divisible by 2).
So right now my program will successfully send all lines that are compiled with word boundary address but the output of the HEX file seems to have a lot of address that are not. For example the second line is 0xb or 11. Is there any way to force them all to word boundaries?
I use the following commands to build
sdas8051 -losg delayms.asm
sdcc -mmcs51 -c extr_intr.c
sdcc -mmcs51 -c isr.c
sdcc -mmcs51 -c ezusb.c
#sdcc -mmcs51 epromProg.c extr_intr.rel isr.rel ezusb.rel delayms.rel -V -verbose
sdcc -mmcs51 epromProg.c extr_intr.rel isr.rel ezusb.rel delayms.rel
And the result
Instead of packihx you can use http://srecord.sourceforge.net and fill the unused bytes over the hexfile.
Thanks. I wouldn't have checked that on my own because I would have assumed it to just convert from HEX to SRECORD but I read it after your recommendation and that does seem like it will work perfectly since there is a blank byte before the odd address in each case. Thanks.
OK, I think I have confused. So I will list out a few things with the hope that someone can clarify.
1. I compiled an ixh file using the example bulk loop project at https://sourceforge.net/projects/fx2lib/ and I ran into two issues:
It has odd addresses
It has multiple cases where it rights to the same memory address more than once.
I also checked out a precompiled program that cypress confirmed works and it had odd addresses as well as memory locations that get programmed twice.
2. So I checked a few example KEIL programs and they have odd address and upload without issues.
That means that either it is doing some sort of packing or padding to overcome the odd addresses or odd addresses really aren't an issue. However I consistently am successful in writing to any block as long as the first byte is even and am unable to write if the first block is odd. Assuming that I am not reading the spec incorrectly that points to some sort of packing or padding.
Does anyone know how other upload programs over come this? Why would it program memory locations more than once?
Why do you think odd addresses are not allowed? Is it somewhere in some spec? Please clarify.
If you have overlapping data in the hexfile I'm sure srecord will complain during conversion. What does it say? And I'm also pretty sure that this is an error in the configuration. Two values can not live at the same address at the same time, now can they?
I am using a Cypress FX2 ASIC and the spec says:
"Note These upload and download requests are always handled by the EZ-USB, regardless of the state of the RENUM bit. The upload start address must be word-aligned (that is, the start address must be evenly divisible by two)."
I realize this is not a generic 8051 issue. Only a cypress issue. I also am confident that SDCC is working just fine because I checked a known working program compiled with KEIL and it has all the same things, so I think SDCC is doing exactly what it is supposed to. My guess is that the cypress tool to upload has additional logic in it. I think I have a work around but I was hoping someone who had written a program to actually upload to a FX2 part could confirm this is the case.
I haven't gotten Srecord to work yet. I tried but during the install it complains that it can't find lcrt1.10.6.o. I spent about 3 hours and found lots of reports on the web but I haven't been able to fix it yet.
Sorry for all the questions.
I wrote a routine which sends the exact same data but makes sure it is all on even word addresses and now I can successfully send a full program to the RAM of a cypress FX2, and read it back and it all matches perfectly.
So from a MAC, I can now compile, and upload to the FX2. Now I just have to write a useful enough program that I prove that the program I am writing is actually running properly.
I only now realized that you are using an Apple OSX Mac and were not talking about a Media Access Control (MAC) driver or something like that. Now I also understand why you have trouble installing srecord and didn't just install it from a prebuilt download. I'm afraid I can't help you there.
If you can't get srecord to work, you can also handle things in your downloader. First load the whole hexfile into memory and then start sending it to the FX2.
It took me much longer than it probably should have but I have verified my issue. I am writing it here in case it helps anyone else with the same issue. I found lots of tools where they wrote both even and odd addresses to the cypress and it worked. The difference was my tool reads it back and if it doesn't match it fails. They never read it back. So I checked and writing to odd addresses works. If you try to read from an odd address it will actually be off by 1 byte. So I write odd addresses as normal, but when I do the read, if they are odd I start by reading one address earlier and throw out the first byte. This works perfectly.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.