Dear Firmware Engineers,

I've just made a first pass at trying to port the H8S from 2329 to 2238. It won't run.

See below for my changes.
Is there anything I've missed?
Is there a "Porting ReadMe" that I could follow?
What should I do next?

Comparing 2329 (old target) with the 2238 (new target):
* Flash PROM: goes from 384K to 256K
* RAM: goes from 32K to 16K
* Crystal: goes from 22.1184 MHz to 12 MHz
* LED Port: goes from Port 2 to Port B

Regards,
Alf Lacis
A.i. Scientific Pty Ltd
10-22 Hornibrook Esplanade
CLONTARF QLD 4019
AUSTRALIA
Ph: (+617 or 07) 3105 5087
www.aiscientific.com
========================================

ParTest.c :
* Change port from Port 2 to Port B (many instances);
* Change partstMAX_LEDs from 7 to 8 (one instance).

FreeRTOSConfig.h :
* configCPU_CLOCK_HZ from 22118400 to 12000000
* configTOTAL_HEAP_SIZE from 15*1024 to 7*1024

main.c :
* mainCOM_TEST_BAUD_RATE from 115200 to 38400

It might be that the number of tasks included in the demo is too many for the reduced amount of RAM. Does vTaskStartScheduler() (in main()) return? If so then it is indicative of not enough RAM to create the idle task.

Try:

1) First verify that your LED outputs are working without the RTOS running - just by turning them on and off within a loop prior to vTaskStartScheduler() being called.

2) Remove all the tasks other than the flash tasks. This can be done by commenting out the functions that create the demo tasks within main(). Comment out the lines vStartIntegerMathsTasks() all the way down to xTaskCreate( vErrorChecks, ...... ), but leaving in the line vStartLEDFlashTasks().

Do the flash tasks then run when they are the only tasks being created?

Regards.

Hi, Richard,<br>
Thanks for your prompt posting.

I already thought of reducing the number of tasks. BTW, the 2238 has only 16K of RAM, which is why I reduced configTOTAL_HEAP_SIZE from 15*1024 to 7*1024.

I also set up some simple flashing before the tasks start:
<H3>int main( void )</H3>
<pre>{
/* Setup the LED's for output. */
vParTestInitialise();

/* For debugging only. */
#define DEBUG_DUMMY_MAX 100000ul
#define DEBUG_CYCLE_MAX 5
/* Block */
{
unsigned long ll;
unsigned char cc;
for ( cc = 0; cc < DEBUG_CYCLE_MAX; cc++ )
{
for ( ll = 0; ll < DEBUG_DUMMY_MAX; ll++ ) { vParTestSetLED(3, 1); }
for ( ll = 0; ll < DEBUG_DUMMY_MAX; ll++ ) { vParTestSetLED(3, 0); }
}
}

/* Start the various standard demo application tasks. */
//vStartIntegerMathTasks( tskIDLE_PRIORITY );
//vAltStartComTestTasks( mainCOM_TEST_PRIORITY, mainCOM_TEST_BAUD_RATE, mainCOM_TEST_LED );
vStartLEDFlashTasks( mainLED_TASK_PRIORITY );
//vStartPolledQueueTasks( mainQUEUE_POLL_PRIORITY );
//vStartMathTasks( tskIDLE_PRIORITY );
//vStartSemaphoreTasks( mainSEM_TEST_PRIORITY );
//vStartDynamicPriorityTasks();
//vStartBlockingQueueTasks( mainBLOCK_Q_PRIORITY );

/* Start the 'Check' task. */
//xTaskCreate( vErrorChecks, (char*)"Check", configMINIMAL_STACK_SIZE, NULL, mainCHECK_TASK_PRIORITY, NULL );

/* In this port, to use preemptive scheduler define configUSE_PREEMPTION
as 1 in portmacro.h. To use the cooperative scheduler define
configUSE_PREEMPTION as 0. */
vTaskStartScheduler();

/* Should never get here! */
return 0;
}
</pre>
No flashing! So I added this also to here:
<H3>void hw_initialise (void)</H3>
<pre>{
vParTestInitialise();
/* Block */
{
unsigned long ll;
unsigned char cc;
for ( cc = 0; cc < DEBUG_CYCLE_MAX; cc++ )
{
for ( ll = 0; ll < DEBUG_DUMMY_MAX; ll++ ) { vParTestSetLED(2, 1); }
for ( ll = 0; ll < DEBUG_DUMMY_MAX; ll++ ) { vParTestSetLED(2, 0); }
}
}

}
</pre>

I can only think of going to "start.asm" next.<br>
Any ideas,<br>
Alf

Are you able to step through the code on the target or in the HEW?

I will have to refamiliarise myself with the port, unfortunately I am travelling a bit today and tomorrow so access to email will be somewhat limited.

Regards.

Hi, Richard,
The 2238 has no on-chip debugging/stepping facilities. There is a simulator in the HEW (Hitachi Embedded Workshop), but AFAIK is really only suitable for Application-level debugging -- certainly not for tracing ISRs.

I have modified 2329S.h to 2238.h with *ONLY* the entries shown in the listing below, and I have modified the two section addresses in the .hwp file using gvim:
-> Replace every occurrence (two) of the string "00FF7C00" with "00FF7000"
(this is the start of on-chip RAM).
->Replace every occurrence (two) of the string "00FFFBFE" with "00FFEFBE"
(this is the top of RAM-1=H'FFFBFF-1 changed to H'FFEFBF-1: Stack Address).

Now, pre-task code has LED functionality (using vParTestSetLED(1, 1);). After the LED task is registered & kernel started, the LEDs do not cycle.

I will review the timer hardware registers -- it's not clear in the original 2329 build what was going on in these hardware registers -- I'll document what is going on & see if the 2238's registers are capable of performing the same function.

Thanks for your suggestions,
Alf Lacis

========================================
#ifndef __2238_h__
#define __2238_h__ 1

// LEDs
#define PEDDR ( *( ( volatile unsigned char * ) 0xFFFE3D ) )
#define PEDR ( *( ( volatile unsigned char * ) 0xFFFF0D ) )
#define PEPCR ( *( ( volatile unsigned char * ) 0xFFFE44 ) )
#define PORTE ( *( ( volatile unsigned char * ) 0xFFFFBD ) )

// Timer
#define MSTPCR ( *( ( volatile unsigned short * ) 0xFFFDE8 ) )
#define TCR1 ( *( ( volatile unsigned char * ) 0xFFFF20 ) )
#define TGR1A ( *( ( volatile unsigned short * ) 0xFFFF28 ) )
#define TIER1 ( *( ( volatile unsigned char * ) 0xFFFF24 ) )
#define TSTR ( *( ( volatile unsigned char * ) 0xFFFEB0 ) )
#define TSR1 ( *( ( volatile unsigned char * ) 0xFFFF25 ) )

// Serial Port
#define SCR1 ( *( ( volatile unsigned char * ) 0xFFFF82 ) )
#define BRR1 ( *( ( volatile unsigned char * ) 0xFFFF81 ) )
#define RDR1 ( *( ( volatile unsigned char * ) 0xFFFF85 ) )
#define SSR1 ( *( ( volatile unsigned char * ) 0xFFFF84 ) )
#define TDR1 ( *( ( volatile unsigned char * ) 0xFFFF83 ) )

#endif // #ifndef __2238_h__
========================================

I'm not familiar with the HEW, but often if you turn off preemption then you can debug in a simulator enough to see where a problem might be. Stepping through the scheduler starting up at least.