Downloading code to the NMIN 2107

[pbro]

We are using the NMIN2107 and are unable to download code to the board. The Sika Monitor runs well and we can execute the erase application area command. Then we execute the 'f' command to download a file, go to the terminal emulator (Minicom) and select an S19 file to download using ASCII transfer with 75ms pause between lines.

So far, so good.

However, we do not know how code a jump vector that must reside at 0x4000, nor do we know how to load the S19 file at an arbitrary address at which the vector is pointing.

We are using the GNU gcc tool chain to generate the code.

Thanks,

[rob]

If you check at the top of page 8 of the manual (V.3), you'll find this:
"If MaxForth is loaded, you can check the memory at location hex 4000 by:
HEX 4000 1 DUMP
0 1 2 3 4 5 6 7 8 9 A B C D E F
4000: 00 00 40 04 73 07 18 13 77 07 77 07 77 08 77 08 ..@.s...w.w.w.w. OK
MaxForth occupies the space from 0x4000 to about 0xFE00. At location 0x4000 is the start vector for MaxForth which is what the bootloader looks for when booting. If the location is 0xFFFFFFFF, then it is assumed that there is no application loaded and the serial loader is run. MaxForth can be replaced by erasing it and writing a new application in its place, making sure that the startup vector for the new application is at 0x4000."

What this is saying is that at location 0x4000, you must have a 32 bit address of the start of your code. In the above example the code starts at 0x4004 so the address at location 0x4000 is 0x4004. At location 0x4004 is the start of the program which must establish the stack pointer and other environmental parameters required to run your program.

If you erase flash memory, location 0x4000 will be all FFs and the bootloader will then load the serial loader and run it. If location 0x4000 is not all FFs, then the bootloader will assume that it is the address of the application to be run and will jump to that address.

Somewhere in your program you need to declare an absolute location and store the start of your program there. This will most likely be done in an assembler file. For the above example it is declared by:
.extern _start

.section vectortable
.export __vector_table
.align 2 /* align on 2-byte range */
__vector_table:
.long _start /* 0 0x000 Reset */

where vectortable has been positioned at 0x4000 by the linker file and _start is the beginning of the application. GNU C might do it differently or not, I'm not sure but it should be similar.

The other thing you want to make sure is that you've converted your .S19 file with the perl script to put it in the right format for the serial downloader.

Rob

[pbro]

Thank you for your suggestions, Rob. We are making some progress, however still have doubts.

We use the gcc option, '-nostartfiles' , and declare what would be our main procedure as '_start()'.

In a separate file, 'vector.s' we put the assembly code that you suggest:

.extern _start

.section vectortable
.export __vector_table
.align 2
__vector_table:
.long _start

Then we link with options --section-start vectortable=0x4000 and -Ttext=0x4004. We do an objdump on the the resulting executable and it shows that the text section is at 0x4004, but no code is shown at 0x4000.

Should there be code for the jump at 0x4000?

Thanks,

Per Bro

[rob]

There shouldn't be code at location 0x4000 but there should be a 32 bit pointer to location 0x4004. So a memory check should yield:
0x4000: 00004004
0x4004: 73071813

The code at location 0x4004 will probably be different depending on what your startup code looks like. Location 0x4000 only contains an address, no code is required as this is just a pointer location for the bootstrap program.

Rob

[pbro]

Hi Rob, thanks again for your help.

We are almost there, I think.

We start with one file, 'vector.s' which has the external directive for _start, and the .section vectortable as noted in your previous reply.

The C program (a.c) is just:

_start() {
int i;

i = 2;
}

This is compiled with:
mcore-elf-gcc -c -nostartfiles a.c vector.s
and linked with
mcore-elf-ld a.o vector.o -Ttext=0x4004
--section-start vectorable=0x4000

This generates an executable file 'a.out' which we can view using:
mcore-elf-objdump -h -s -D a.out

The output listing shows the section .text @ 0x4004 and the section vectortable @ 0x4000. The contents of section vectortable are 04400000. This sounds a bit like the address 4004, but reversed (big-endian?).

My first question is whether we should be generating big of little endian code?

The disassembly of the section .text looks fine, with the asm code as we would expect.

The we pass the executable code through the translation program to obtain an S19 file:
mcore-elf-objcopy -Osrec a.out a.s19

The resulting file is something like:

0080000612E.....
S0080000612E7.....
S1134004F02.....
S107401fF....
S9034004B

I don't know if this is correct, but I assume it is OK.

Then we pass this through the sikadown.pl, which gives:

4004F000FFFFFFFFFFF.......
1014F000FFFFFFFFF.......
9999999999999999999............

Then we download this to the MCore board. using the sika monitor, erasing first the application part of flash with 'e' and then sending the file with 'f', under minicom .

After pressing 'f' and selecting the file the program just sits there as though nothing is being downloaded. We download as ASCII and put 75ms between lines.

So, the questions are:

1. Does the S19 code look OK?
2. Does the sikadown code look OK?
3. Do you note any procedural error in the downloading of the sikadown'ed file?

Thanks,

Per Bj. Bro

[rob]

This is the first two lines from my download file:

00004000000040047307181...
000040407204A4023004600...

So it looks like your endian or something might be wrong.

When you download, you should see something like this:

MMC2107 (Sika) Flash Programmer
: e
Erasing application.
Done.
: f
Program flash.
Send file now.
.................................
Done.
:

The dots are sent after each good line is programmed. If you don't
get any dots, then your downloading is a problem. This could be an
endian problem or line delay problem. I did my download with a delay
of 167ms per line to be sure. You get the Done. after the last line,
which is all 9's, is downloaded. If you don't get that, then there
could be a delay per line problem or there might be a blank line just
before the line of 9's. Sometimes the Perl script will do that. Edit
the file and remove any blank lines.

Answers:

1. Your s19 file looks funny because every line should start with an
S. The first few lines of my file look like:
S0030000FC
S3210001FC000000A55A0000D5...
S3210001FC1C00000000000000...
S309000040000000400472
S321000040047307181377...
Note that the srecords are in S3 format which is 32 bit addresses.
I'm not sure, but the script might be expecting that. Also in your
file excerpt, I don't see a line for memory location 0x4000 which
is needed. My line for this is: S309000040000000400472
If you can't get GNU to pop out this line, you could add it to the
s19 file manually.
2. The sikadown output looks odd but that could be due to the S1 records
you are using.
3. Procedurally you sound fine but you could try to increase the line
delay and try and get dots for each line sent.

Rob

[pbro]

Hi Rob,

I guess that we're not generating the correct format for our object files. In your example file, you have lines which start with S3, and I would guess that the last line of that file starts with S7, but in our file the lines start with S1 and the last line starts with an S9.

Motorolas formats are S1 and S9 for 16 bit address files, S2 and S8 for 24 bit files, S3 and S7 for 32 bit files, so it seems that our first error is that we're generating a file with 16 bit addresses, not 32 bit addresses. This would then cause all the other errors as you mentioned.

Does this sound reasonable?

I read in the gcc (and gas) docs that one "can" generate 16 code if one wishes, with the .code16 and .code32 directives. I assume we are really generating 32 bit code with our mcore-elf-gcc tool chain, as the gas docs say that this is the default.

So...I reckon that our error is in the use of the objcopy utility. Probably, we are compiling and assembling correctly, but the output is a binary executable file, not a hex S record file.

How do we translate a binary executable to an S record flie in suitable format for downloading to the board?

Thanks again for you help, Rob.

[pbro]

Hi Rob,

We found an option to the objcopy utility, --srec-forceS3 which in combination with the -Osrec option will generate S37 files. So, we continue to progress a bit...

Ciao,

Per

[rob]

Here's a tool from Motorola which is quite useful for massaging s-records into different formats: sreccvt (https://e-www.motorola.com/webapp/Download?colCode=SRECCVTSW&prodCode=MC9S12E128&appType=license&location=psp)

Rob

[pbro]

Hi Rob,

I'm including a screen dump of the processes we're using to generate the downloadable file . The original C code is simply assignment of a constant (2) to a declared integer, as listed earlier in the thread.

After compiling and assembling with the directives to locate the section vectortable at 0x4000, and the text at 0x4004, we execute the objcopy routine

///////////////////////////////////////////////////////////////////////
The resulting file is:

S0080000612E7331398B
S0080000612E7331398B
S31500004004F0242098081227600897721280122088DC
S30900004014F020CF00C3
S70500004004B6

////////////////////////////////////////////////////////////////
We then sikadown:

sikadown v0.1 9/12/2000 AM
infile: a.s37
outfile: a.txt
----------------------------------------------------------
S-Record end
----------------------------------------------------------
and the resulting file is:

00004000FFFFFFFFF0242098081227600897721280122088F020CF00FFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFF
99999999999999999999999999999999999999999999999999999999999999999999999999999999
999999999999999

//////////////////////////////////////////////////////////////////////
Then we try to download to the board, using about 200ms between lines and 5ms between characters. The code downloads, but generates an error:

Error page address: 00004000

and stops.

Do you see a problem?

Thanks,

Per

[rob]

It looks like your lines are truncated. The sika compiler generates long lines (137 characters) so be careful they are not truncated anywhere. The last two lines of my file are (they are broken into several lines by this poster):

0001FC000000A55A0000BE140000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

The other problem is with the location 0x4000. Your S19 file has nothing at that location so when the sika script translates it to download format, it just inserts FF's there. This will cause the bootloader to sense that there is no program to run. You want to have the address of the start of your program at that location. If you already have that in your program, then it might be getting optimized out of the compile because there are no references to that location. You need to make that location an always included location either with linker declarations or compiler options.

Rob

[pbro]

Hi Rob,

We're moving ahead slowly, though still not able to program the M-Core board. I'ld like to confirm one small point.

We should be generating S37 records, right?

We were generating S19 records (16 bit addresses) but then, in comparason with your files, found that you had S3 records. The S3 records are for 32 bit addresses, while the S1 records are for 16 bit addresses. It looks like gcc generates S1 by default, but we can add a linker option to generate S3. I'll send this query on to Peter Barada and Brian LaPonsey also, later on today.

Thanks,

Per Bj. Bro

[rob]

Yes, go for S37 records.

Rob

[pbro]

Hi there Rob.

We've solved one more problem: endianess.

We've been compiling and linking for a little endian processor. Now, including the compile and linke parameter -EB, the section vectortable comes out with the correct contents, just like yours, at address 0x4000 and contents 0x4004, not backwards.

The objdump utility confirms the format of the file and the presence of the vectortable section.

However, when we run the objcopy utility to generate the S37 records, we don't get the line from the vectortable section. So, I guess that we're not running the objcopy utility correctly.

I run through a man on the objcopy utility and I can't tell how to ensure that all sections are inclued in the copy operation.

Do you have a suggestion about where to find out about this?

Atte.,

Per Bj. Bro

[pbro]

Hello Rob,

Would it be possible for you to put 2 small files on the forum for us? We would like to test our downloading from PC->M-Core, and we aren't sure if our files are bad, or if our downloading is not working correctly.

One file would be an S37 record file, and the other would be the same file but processed by the sikadown.pl utility. The files don't have to do anything, for example, we've just been assigning the constant 2 to an integer variable, nothing more.

We want to have something that we know is correctly compiled, assembled and linked. This way we can determine if our downloading procedure is correct or not.

Thanks,

Per

[nmitech]

I hope the thread below is answer your previous questions. Let us know how thing is going.

http://www.newmicros.com/discussion/showthread.php?threadid=533

[pbro]

Thanks for your note,

In fact, we have not been able to solve the problem using the procedure suggested in the cross post. The Sika monitor is working, that's for sure. It gives us the prompt and tells us to download the file after we erase the application sector of memory. However, when we go download the file, using minicom under Linux, hyperterminal under Windows or the terminal program / settings for Windows that NewMicros sent us, the download does not register transmission of any lines at all. No dots are printed to the screen, and an error is generated about the page fault at address 0x4000.

I purchased a new board to check if the new hardware will solve the problem, but haven't taken it out of the box yet. If the new board solves, the problem, then I might request a return authorization for the old one. I'll let you know.

Again, thanks for your assistance.

P.B.Bro

[pbro]

We've just tried the newly purchased M-Core board and unfortunately downloading code produces errors. We are downloading sample code sent by Rob (I might be mistaken regarding identity) which I think was generated with Forth. It's an 80Kbyte file with line length of 136 characters. We assume that it was previously processed by sikadown.pl.

The Sika monitor is running; it gives the prompt and accept commands. We erase the application area with the 'e' command. then request download with the 'f' command. Then we download the file with the ASCII protocol, using 100ms delays between lines.

The monitor generates errors which read
error page address 00004000
error page address 00004040
error page address 00004080
and so on...

The terminal program keeps sending the file, up to the 80Kbytes, but the monitor program does not respond, and specifically, does not send dots for each line received.

Note that this is the response using hyperterminal under Windows. Using minicom under Linux gives similar results.

[nmitech]

1. Down load the NMITerm, terminal program and install on your PC instead of using HyperTerminal program.
http://www.newmicros.com/download/NMITerm.zip

2. Run the NMITerm program and setup as below,
Click on Options, Settings, and set baudrate for 19200, 8N1. Also select your working ComPort(1,2,3,4,etc...) then click on ASCII setting TAB, under ASCII receiving set the Line Pacing to 0 (DEC) then go up to ASCII Sending and set the LINE DELAY for 100ms. Click on APPLY to save the new settings.

3. Apply power to your NMIN-2107, you will see this on the NMITerm screen,

MMC2107 (Sika) Flash Programmer
:

now enter e to erase application program. Please don't skip this step, just to make sure the flash is cleaned

next enter f but do not hit enter key. Just click on FILE and Send File "mfcoreapp51b.sp" i email you.

while the file is downloading, it will display

.....................................................................
......................................................................
....................................................................
................................................................
....................................................................

Done.
:


Now press the reset switch, it will respond with,
Max-FORTH V5.1B
and each time you hit enter key it will respond with,
OK

Seeing This message means your board is communicating and flashed properly. Hope this works out for you.

Also email me nmitech@newmicros.com the file that Rob sent you. I want to try it on my board. Thanks!

[pbro]

Thank you for your prompt reply.

I think we are on the way to a solution. We upped the input voltage to about 15Vdc, and the downloading now works. The Forth program appears, so the basic problem has been solved.

We still have problems in that the reset button doesn't reset the machine, even if we short out PA7 to +3Vdc, but we'll look into this later.

Regards,

P.B.Bro